10 ms·

Let me start by saying (as someone who has written a few technical books of his own)—Congratulations! I am sure you (assuming this is your first book) are lear

by raju 2y ago

Let me start by saying (as someone who has written a few technical books of his own)—Congratulations! I am sure you (assuming this is your first book) are learning that this is a labor of love, and I wish you the very best in this endeavor. You should be proud! I was exposed to "data oriented programming" thanks to Clojure—wherein maps/sets are the constructs used to pass data (as plain data) around, with simple functions that work with the data, as opposed to the traditional OO (hello ORM) that mangles data to fit some weird hierarchy. Java's recent innovations certainly make this a lot easier, and I am glad someone is looking at propagating a much needed message. I will take a look at the book, but I wish you the very best.

mrbonner 2y ago
I am also very interested in how this work in practice. With OOP at least you know the shape of your data structure as opposed to the hash map as a mere container type.
- akavi 2y ago
  You can get strongly typed "shaped" data without objects[0], even in Java: Records[1]. ~Unfortunately, I believe they're mutable (and cannot be made immutable).~ Edit: I was wrong, they're immutable. [0]: I'm using "object" to mean "data bound to methods", since the concept of aggregate data in general long pre-date OOP (eg, C's structs) [1]: https://docs.oracle.com/en/java/javase/17/language/records.html https://docs.oracle.com/en/java/javase/17/language/records.h...
  - bedatadriven 2y ago
    A record's fields are final, so records are immutable (though they can include immutable pointers to mutable objects)
  - taftster 2y ago
    Java Records are immutable (by the most common definition). They don't have any means to update the record (via setters, etc.) after construction. That doesn't mean, for example, you can't store a reference to a mutable type (for example, a List or Map) in your record. The frustration I have with Records is there is no good way to prevent direct construction of them. That is, the constructor is public, which prevents an easy way of enforcing an invariant during construction. For example, let's say that you have a record with a Date type. There's no good way to prevent a user from creating the record with an invalid date, one that is out of a needed date range. Or maybe enforcing a field cannot be null or some combination of fields must meet requirements as a group. The benefit I get from the classic Builder pattern is defeated with Records. I can't enforce checking of my fields before the construction of the record object itself. Presumably I would need to verify the object after construction, which is unfortunate.
    - akavi 2y ago
      Can you make the Record class private to a module, and only export a static function that constructs them? (I know very little about Java)
      - kaba0 2y ago
        To a degree, yes, that’s possible. But leaking a private type over module boundaries is bad form, so a better (though possibly over engineered solution) would be to have a separate public interface, implemented by the private record type, and the static function would have that interface as return type.
        enugu 2y ago
        Why is it bad form to expose a record type only via custom functions and not its field accessors? Isn't this just like exposing a more usual object with its public functions and private functions remain inaccessible?
    - vips7L 2y ago
      You can enforce some invariants during construction: record Point(int x, int y) { Point { if (x < 0) throw new IllegalArgumentException() } } or if you want to assert something is not null: record Person(String name) { Person { requireNonNull(name); } }
      - nogridbag 2y ago
        I think records will be much more useful if https://openjdk.org/jeps/468 https://openjdk.org/jeps/468 gets out of preview.
    - snmx999 2y ago
      You can create dedicated, already verified objects to pass on to your record. E.g. AllowedDate (extends Date).
    - 2y ago
- geophile 2y ago
  I am an OOP programmer going back to the late 80s (including the cfront days of C++), and a serious user of Python since 2007. In Python, I sometimes try data-oriented programming, using lists and dicts to structure data. And I find that it does not work well. Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on, which is not helped by Python's lack of strong typing. In these situations, I often introduce objects that wrap the map or dict, and have methods that make sense for that level. In other words, the objects can be viewed as providing clear documentation for the whole nested structure, and how it can be navigated.
  - deleted 2y ago
    [deleted]
  - goostavos 2y ago
    >Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on Author here, I agree with you. I have the working memory of a small pigeon. The flavor of data orientation we cover in the book leverages strongly typed representations of data (as opposed to using hash maps everywhere). So you'll always know what's shape it's in (and the compiler enforces it!). We spend a lot of time exploring the role that the type system can play in our programming and how we represent data.
    - joshlemer 2y ago
      Given the strongly typed flavour of data oriented programming, I wonder if you have any thoughts on the "proliferation of types" problem. How to avoid, especially in a nominally typed language like Java, an explosion of aggregate types for every context where there may be a slight change in what fields are present, what their types are, and which ones are optional. Basically, Rich Hickey's Maybe Not talk. record Make(makeId, name) record Model(modelId, name) record Car(make, model, year) record Car(makeId, modelId, year) record Car(make, model) record Car(makeId, modelId) record Car(make, year) record Car(makeId, year) record Car(make, model, year, colour) record Car(makeId, modelId, year, colour) record Car(year, colour) ....
- kccqzy 2y ago
  Clojure has spec. That allows you to know a specification of what the data structure contains.
- davedx 2y ago
  With TypeScript you have types to tell you the shape of your data.
goostavos 2y ago
Thanks for the kind words :) >learning that this is a labor of love I underestimated both the amount of labor and the amount of love that would be involved. There were more than a few "throw everything out and start over" events along the way to this milestone. Clojure definitely had a huge impact on how I think about software. Similarly, Haskell and Idris have rearranged my brain. However, I still let Java be Java. The humble object is really tough to beat for managing many kinds of runtime concerns. The book advocates for strongly typed data and leveraging the type system as a tool for thinking. >Java's recent innovations certainly make this a lot easier Yeah, it's an exciting time! Java has evolved so much. Algebraic types, pattern matching, `with` expressions -- all kinds of goodies for dealing with data.
- jwr 2y ago
  > Clojure definitely had a huge impact on how I think about software I could be called a "Clojure programmer", because I make a living from an app written Clojure and ClojureScript. While I always appreciated the incredible JVM, I always looked at Java the language with disgust and contempt, interfacing with it only as was necessary, but recent work on Java makes it much more attractive. I was impressed by the functional interfaces, modern design with mostly static methods, JSR-310 (date and time) is absolutely great — overall, Java has improved a lot over the years. It has come to the point where I gasp might consider writing some Java code :-)

by raju 2y ago

mrbonner 2y ago

I am also very interested in how this work in practice. With OOP at least you know the shape of your data structure as opposed to the hash map as a mere container type.

akavi 2y ago
You can get strongly typed "shaped" data without objects[0], even in Java: Records[1]. ~Unfortunately, I believe they're mutable (and cannot be made immutable).~ Edit: I was wrong, they're immutable. [0]: I'm using "object" to mean "data bound to methods", since the concept of aggregate data in general long pre-date OOP (eg, C's structs) [1]: https://docs.oracle.com/en/java/javase/17/language/records.html https://docs.oracle.com/en/java/javase/17/language/records.h...
- bedatadriven 2y ago
  A record's fields are final, so records are immutable (though they can include immutable pointers to mutable objects)
- taftster 2y ago
  Java Records are immutable (by the most common definition). They don't have any means to update the record (via setters, etc.) after construction. That doesn't mean, for example, you can't store a reference to a mutable type (for example, a List or Map) in your record. The frustration I have with Records is there is no good way to prevent direct construction of them. That is, the constructor is public, which prevents an easy way of enforcing an invariant during construction. For example, let's say that you have a record with a Date type. There's no good way to prevent a user from creating the record with an invalid date, one that is out of a needed date range. Or maybe enforcing a field cannot be null or some combination of fields must meet requirements as a group. The benefit I get from the classic Builder pattern is defeated with Records. I can't enforce checking of my fields before the construction of the record object itself. Presumably I would need to verify the object after construction, which is unfortunate.
  - akavi 2y ago
    Can you make the Record class private to a module, and only export a static function that constructs them? (I know very little about Java)
    - kaba0 2y ago
      To a degree, yes, that’s possible. But leaking a private type over module boundaries is bad form, so a better (though possibly over engineered solution) would be to have a separate public interface, implemented by the private record type, and the static function would have that interface as return type.
      - enugu 2y ago
        Why is it bad form to expose a record type only via custom functions and not its field accessors? Isn't this just like exposing a more usual object with its public functions and private functions remain inaccessible?
  - vips7L 2y ago
    You can enforce some invariants during construction: record Point(int x, int y) { Point { if (x < 0) throw new IllegalArgumentException() } } or if you want to assert something is not null: record Person(String name) { Person { requireNonNull(name); } }
    - nogridbag 2y ago
      I think records will be much more useful if https://openjdk.org/jeps/468 https://openjdk.org/jeps/468 gets out of preview.
  - snmx999 2y ago
    You can create dedicated, already verified objects to pass on to your record. E.g. AllowedDate (extends Date).
  - 2y ago
geophile 2y ago
I am an OOP programmer going back to the late 80s (including the cfront days of C++), and a serious user of Python since 2007. In Python, I sometimes try data-oriented programming, using lists and dicts to structure data. And I find that it does not work well. Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on, which is not helped by Python's lack of strong typing. In these situations, I often introduce objects that wrap the map or dict, and have methods that make sense for that level. In other words, the objects can be viewed as providing clear documentation for the whole nested structure, and how it can be navigated.
- deleted 2y ago
  [deleted]
- goostavos 2y ago
  >Once I get two or more levels of nesting, I find it far too easy to get confused about which level I'm on Author here, I agree with you. I have the working memory of a small pigeon. The flavor of data orientation we cover in the book leverages strongly typed representations of data (as opposed to using hash maps everywhere). So you'll always know what's shape it's in (and the compiler enforces it!). We spend a lot of time exploring the role that the type system can play in our programming and how we represent data.
  - joshlemer 2y ago
    Given the strongly typed flavour of data oriented programming, I wonder if you have any thoughts on the "proliferation of types" problem. How to avoid, especially in a nominally typed language like Java, an explosion of aggregate types for every context where there may be a slight change in what fields are present, what their types are, and which ones are optional. Basically, Rich Hickey's Maybe Not talk. record Make(makeId, name) record Model(modelId, name) record Car(make, model, year) record Car(makeId, modelId, year) record Car(make, model) record Car(makeId, modelId) record Car(make, year) record Car(makeId, year) record Car(make, model, year, colour) record Car(makeId, modelId, year, colour) record Car(year, colour) ....
kccqzy 2y ago
Clojure has spec. That allows you to know a specification of what the data structure contains.
davedx 2y ago
With TypeScript you have types to tell you the shape of your data.

goostavos 2y ago

Thanks for the kind words :) >learning that this is a labor of love I underestimated both the amount of labor and the amount of love that would be involved. There were more than a few "throw everything out and start over" events along the way to this milestone. Clojure definitely had a huge impact on how I think about software. Similarly, Haskell and Idris have rearranged my brain. However, I still let Java be Java. The humble object is really tough to beat for managing many kinds of runtime concerns. The book advocates for strongly typed data and leveraging the type system as a tool for thinking. >Java's recent innovations certainly make this a lot easier Yeah, it's an exciting time! Java has evolved so much. Algebraic types, pattern matching, `with` expressions -- all kinds of goodies for dealing with data.

jwr 2y ago
> Clojure definitely had a huge impact on how I think about software I could be called a "Clojure programmer", because I make a living from an app written Clojure and ClojureScript. While I always appreciated the incredible JVM, I always looked at Java the language with disgust and contempt, interfacing with it only as was necessary, but recent work on Java makes it much more attractive. I was impressed by the functional interfaces, modern design with mostly static methods, JSR-310 (date and time) is absolutely great — overall, Java has improved a lot over the years. It has come to the point where I gasp might consider writing some Java code :-)