10 ms·

Another big reason is the lack of value types in languages like Java. Modern languages with a GC tend to have those, and where it makes sense to use them they h

Another big reason is the lack of value types in languages like Java. Modern languages with a GC tend to have those, and where it makes sense to use them they help, a lot.

amelius 3y ago
What are "value types"?
- greesil 3y ago
  In Java, primitives. int, boolean, float. Allocated on the stack, or the heap along with the object it is a part of.
- jstimpfle 3y ago
  If you nest an object within another object you often want to embed the child directly in its parent, sharing the memory and avoiding the indirection that you get if you nest with a reference as is the typical approach with GC languages. Also embedding makes it clear that it's a 1:1 relation, i.e. non-optional, fixed identity etc. AFAICT few GC languages allow you to do this, basically you have to buy into indirection and end up with webs of objects. This is quite cache unfriendly, but the bigger issue for me is that it makes the code less clear and requires additional complexities since you can't just jump from a child to its parent by subtracting an offset from its address.
  - ghusbands 3y ago
    > makes the code less clear and requires additional complexities since you can't just jump from a child to its parent by subtracting an offset from its address. Wait, so you're saying that code that subtracts an offset from a child node to get to a parent node is clearer and less complex than alternatives?
    - groestl 3y ago
      > Wait, so you're saying that code that subtracts an offset from a child node to get to a parent node is clearer and less complex than alternatives? Parent made me laugh out loud on this.
      - jstimpfle 3y ago
        I hope you've stopped laughing and can read and understand my answer.
        groestl 3y ago
        Please, I did not want to offend you personally. It just took me by surprise. I understand your points, even though I'm with your direct reply, all things considered.
        jstimpfle 3y ago
        The address offset subtraction thing specifically is used quite a bit in the Linux kernel for example. It allows to combine abstract code with concrete data. For example they define a red-black tree as a graph of just plain nodes. These nodes are totally abstract, they contain only node pointers but no useful data. The code is totally abstract, no need to instanciate anything a dozen times with different offsets and such. You simply wrap the abstract nodes with whatever concrete useful data you fancy. The same approach works for lists and a variety of other data structures. You can get from the abstract link node to the containing struct with a macro: CONTAINER_OF(ptr, containertype, membername). It's easy to use and unlikely to get it wrong.
    - jstimpfle 3y ago
      Not having the address relationship requires additional complexities. To get from the child to the parent, you need to spend an additional reference field, and need to keep it consistent with the other reference. If you embed directly, there's nothing in the relationship of the objects' identities that could ever get consistent. It's a strong guarantee. How do you get from the child to the parent in, say Java? And how do you tell that a child is never swapped out? How do you copy an object that holds, say 4 vec4, vec4 being a struct that itself 4 holds floats? With value types, say in C, it's 1 memcpy and you're done.
pjmlp 3y ago
Note about "modern languages with GC", this was already a thing in Common Lisp, Eiffel, Modula-2+, Modula-3, Mesa/Cedar, Oberon (and its linage),... Java's mistake was ignoring them, as its was designed as set-top box programming language as Oak, pivoted to applets, and then pushed all over the place.
- foldr 3y ago
  The poster is talking about the subset of modern languages that have GC. They're not suggesting that only modern languages have GC.
  - pjmlp 3y ago
    > "Another big reason is the lack of value types in languages like Java. Modern languages with a GC tend to have those, and where it makes sense to use them they help, a lot." Might be interpreted as older languages with GC did not had value types, which is bluntly false, going back to 1970's. My remark was to make clear this isn't something new and modern, rather a design mistake in languages like Java, that is now trying really hard to fix it, while others designed after it (like C#), thankfully didn't follow the same trap. How modern a 2001 language (C#), using ideas from Mesa/Cedar (1985), is an exercise in the semantics of "modern".
    - foldr 3y ago
      >Might be interpreted as older languages with GC did not had value types, which is bluntly false, going back to 1970's. Ok, but you included Common Lisp in your list, which doesn't really have value types. (E.g. you cannot make an unboxed array of structs.)
      - pjmlp 3y ago
        No, but you can have an array of primitive values, instead of an array of pointers.
        3y ago

Another big reason is the lack of value types in languages like Java. Modern languages with a GC tend to have those, and where it makes sense to use them they help, a lot.

amelius 3y ago

What are "value types"?

greesil 3y ago
In Java, primitives. int, boolean, float. Allocated on the stack, or the heap along with the object it is a part of.
jstimpfle 3y ago
If you nest an object within another object you often want to embed the child directly in its parent, sharing the memory and avoiding the indirection that you get if you nest with a reference as is the typical approach with GC languages. Also embedding makes it clear that it's a 1:1 relation, i.e. non-optional, fixed identity etc. AFAICT few GC languages allow you to do this, basically you have to buy into indirection and end up with webs of objects. This is quite cache unfriendly, but the bigger issue for me is that it makes the code less clear and requires additional complexities since you can't just jump from a child to its parent by subtracting an offset from its address.
- ghusbands 3y ago
  > makes the code less clear and requires additional complexities since you can't just jump from a child to its parent by subtracting an offset from its address. Wait, so you're saying that code that subtracts an offset from a child node to get to a parent node is clearer and less complex than alternatives?
  - groestl 3y ago
    > Wait, so you're saying that code that subtracts an offset from a child node to get to a parent node is clearer and less complex than alternatives? Parent made me laugh out loud on this.
    - jstimpfle 3y ago
      I hope you've stopped laughing and can read and understand my answer.
      - groestl 3y ago
        Please, I did not want to offend you personally. It just took me by surprise. I understand your points, even though I'm with your direct reply, all things considered.
        jstimpfle 3y ago
        The address offset subtraction thing specifically is used quite a bit in the Linux kernel for example. It allows to combine abstract code with concrete data. For example they define a red-black tree as a graph of just plain nodes. These nodes are totally abstract, they contain only node pointers but no useful data. The code is totally abstract, no need to instanciate anything a dozen times with different offsets and such. You simply wrap the abstract nodes with whatever concrete useful data you fancy. The same approach works for lists and a variety of other data structures. You can get from the abstract link node to the containing struct with a macro: CONTAINER_OF(ptr, containertype, membername). It's easy to use and unlikely to get it wrong.
  - jstimpfle 3y ago
    Not having the address relationship requires additional complexities. To get from the child to the parent, you need to spend an additional reference field, and need to keep it consistent with the other reference. If you embed directly, there's nothing in the relationship of the objects' identities that could ever get consistent. It's a strong guarantee. How do you get from the child to the parent in, say Java? And how do you tell that a child is never swapped out? How do you copy an object that holds, say 4 vec4, vec4 being a struct that itself 4 holds floats? With value types, say in C, it's 1 memcpy and you're done.

pjmlp 3y ago

Note about "modern languages with GC", this was already a thing in Common Lisp, Eiffel, Modula-2+, Modula-3, Mesa/Cedar, Oberon (and its linage),... Java's mistake was ignoring them, as its was designed as set-top box programming language as Oak, pivoted to applets, and then pushed all over the place.

foldr 3y ago
The poster is talking about the subset of modern languages that have GC. They're not suggesting that only modern languages have GC.
- pjmlp 3y ago
  > "Another big reason is the lack of value types in languages like Java. Modern languages with a GC tend to have those, and where it makes sense to use them they help, a lot." Might be interpreted as older languages with GC did not had value types, which is bluntly false, going back to 1970's. My remark was to make clear this isn't something new and modern, rather a design mistake in languages like Java, that is now trying really hard to fix it, while others designed after it (like C#), thankfully didn't follow the same trap. How modern a 2001 language (C#), using ideas from Mesa/Cedar (1985), is an exercise in the semantics of "modern".
  - foldr 3y ago
    >Might be interpreted as older languages with GC did not had value types, which is bluntly false, going back to 1970's. Ok, but you included Common Lisp in your list, which doesn't really have value types. (E.g. you cannot make an unboxed array of structs.)
    - pjmlp 3y ago
      No, but you can have an array of primitive values, instead of an array of pointers.
      - 3y ago