3 ms·

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus If your data structures don't exist outs

by jbooth 13y ago

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." -- Linus If your data structures don't exist outside of your functional code acting on them, it's hard to reason about the data structures themselves in a vacuum.

weavejester 13y ago
Isn't this an argument against hiding your data structures behind an opaque object structure?
- jbooth 13y ago
  To my mind, it's an argument for explicit definition of data structures (from me, not Linus). It seems to me that structs and/or objects do that pretty well. I'm not sure what you're talking about with 'opaque object structure'. class MyClass { member1, member2 } seems pretty transparent to me. Anyways, I was just explaining why many people prefer to have struct/object definitions separated from the code that operates on them. YMMV, you don't have to agree.
  - weavejester 13y ago
    If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys. I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.
    - jbooth 13y ago
      "It's hard to transverse them, or to merge them, or often even to look up a list of keys." That's exactly what I'm arguing against in my comment on making your important structs/objects and their relationships explicit. Randomly mutating them together all over your program might seem more flexible but at a cost of making you worry about your code rather than your data definitions. And that's without even getting into performance implications. If you actually need a Map, of course, that's a different situation than the ones I'm thinking.
      - weavejester 13y ago
        Using a map doesn't necessarily mean random mutation, or giving up on your type system. In languages with immutable data structures and a sophisticated type system, you can type-check the keys and values in a map.

by jbooth 13y ago

weavejester 13y ago

Isn't this an argument against hiding your data structures behind an opaque object structure?

jbooth 13y ago
To my mind, it's an argument for explicit definition of data structures (from me, not Linus). It seems to me that structs and/or objects do that pretty well. I'm not sure what you're talking about with 'opaque object structure'. class MyClass { member1, member2 } seems pretty transparent to me. Anyways, I was just explaining why many people prefer to have struct/object definitions separated from the code that operates on them. YMMV, you don't have to agree.
- weavejester 13y ago
  If you're just treating a object as a map of keys to values, then it can be fairly transparent, but unless you're using a language like Javascript, where maps and objects are synonymous, objects are much more difficult to work with. It's hard to transverse them, or to merge them, or often even to look up a list of keys. I'd suggest that a better solution would be to just use maps, at least in languages with good support for raw data structures.
  - jbooth 13y ago
    "It's hard to transverse them, or to merge them, or often even to look up a list of keys." That's exactly what I'm arguing against in my comment on making your important structs/objects and their relationships explicit. Randomly mutating them together all over your program might seem more flexible but at a cost of making you worry about your code rather than your data definitions. And that's without even getting into performance implications. If you actually need a Map, of course, that's a different situation than the ones I'm thinking.
    - weavejester 13y ago
      Using a map doesn't necessarily mean random mutation, or giving up on your type system. In languages with immutable data structures and a sophisticated type system, you can type-check the keys and values in a map.