<story><title>Show HN: I Wrote a Book on Java</title><text>&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-java&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-j...&lt;/a&gt;&lt;p&gt;This book is a distillation of everything I’ve learned about what effective development looks like in Java (so far!). It&amp;#x27;s about how to organize programs around data &amp;quot;as plain data&amp;quot; and the surprisingly benefits that emerge when we do. Programs that are built around the data they manage tend to be simpler, smaller, and significantly easier understand.&lt;p&gt;Java has changed radically over the last several years. It has picked up all kinds of new language features which support data oriented programming (records, pattern matching, `with` expressions, sum and product types). However, this is not a book about tools. No amount of studying a screw-driver will teach you how to build a house. This book focuses on house building. We&amp;#x27;ll pick out a plot of land, lay a foundation, and build upon it house that can weather any storm.&lt;p&gt;DoP is based around a very simple idea, and one people have been rediscovering since the dawn of computing, &amp;quot;representation is the essence of programming.&amp;quot; When we do a really good job of capturing the data in our domain, the rest of the system tends to fall into place in a way which can feel like it’s writing itself.&lt;p&gt;That&amp;#x27;s my elevator pitch! The book is currently in early access. I hope you check it out. I&amp;#x27;d love to hear your feedback.&lt;p&gt;You can get 50% off (thru October 9th) with code `mlkiehl`
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-java&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-j...&lt;/a&gt;</text></story><parent_chain><item><author>joshlemer</author><text>Given the strongly typed flavour of data oriented programming, I wonder if you have any thoughts on the &amp;quot;proliferation of types&amp;quot; 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&amp;#x27;s Maybe Not talk.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    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)
    
    ....&lt;/code&gt;&lt;/pre&gt;</text></item><item><author>goostavos</author><text>&amp;gt;Once I get two or more levels of nesting, I find it far too easy to get confused about which level I&amp;#x27;m on&lt;p&gt;Author here, I agree with you. I have the working memory of a small pigeon.&lt;p&gt;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&amp;#x27;ll always know what&amp;#x27;s shape it&amp;#x27;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.</text></item><item><author>geophile</author><text>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.&lt;p&gt;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&amp;#x27;m on, which is not helped by Python&amp;#x27;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.</text></item><item><author>mrbonner</author><text>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.</text></item><item><author>raju</author><text>Let me start by saying (as someone who has written a few technical books of his own)—Congratulations!&lt;p&gt;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!&lt;p&gt;I was exposed to &amp;quot;data oriented programming&amp;quot; thanks to Clojure—wherein maps&amp;#x2F;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.&lt;p&gt;Java&amp;#x27;s recent innovations certainly make this a lot easier, and I am glad someone is looking at propagating a much needed message.&lt;p&gt;I will take a look at the book, but I wish you the very best.</text></item></parent_chain><comment><author>PaulHoule</author><text>Hickey is great at trash-talking other languages.  In the case of Car you might build a set of builders where you write&lt;p&gt;&lt;pre&gt;&lt;code&gt;   Car.builder().make(“Buick”).model(“LeSabre”).build()
&lt;/code&gt;&lt;/pre&gt;
Or in a sane world code generate a bunch of constructors.&lt;p&gt;In the field of ontology (say OWL and RDF) there is a very different viewpoint about ‘Classes’ in the objects gain classes as they gain attributes.  :Taylor_Swift is a :Person because she has a :birthDate, :birthPlace and such but was not initially a :Musician until she :playsInstrument, :recordedTrack, :performedConcert and such.  Most languages have object systems like Java or C++ where a Person can’t start out as not a Musician but become one later like the way they can in real life.&lt;p&gt;Notably in a system like the the terrible asymmetry of where does an attribute really belong is resolved,  as in real life you don’t have to say it is primary that Taylor Swift recorded the Album Fearless or that Fearless was recorded by Taylor Swift.&lt;p&gt;It’s a really fascinating question in my mind how you create a ‘meta object facility’ that puts a more powerful object system on your fingers in a language like Java or Python,  for instance you can have something like&lt;p&gt;&lt;pre&gt;&lt;code&gt;   taylorSwift.as(Musician.class)
&lt;/code&gt;&lt;/pre&gt;
which returns something that implements the Musician.class interface if&lt;p&gt;&lt;pre&gt;&lt;code&gt;   taylorSwift.isA(Musician.class)
&lt;/code&gt;&lt;/pre&gt;
where&lt;p&gt;&lt;pre&gt;&lt;code&gt;   TaylorSwift instanceof MetaObject.class&lt;/code&gt;&lt;/pre&gt;</text></comment>
<story><title>Show HN: I Wrote a Book on Java</title><text>&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-java&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-j...&lt;/a&gt;&lt;p&gt;This book is a distillation of everything I’ve learned about what effective development looks like in Java (so far!). It&amp;#x27;s about how to organize programs around data &amp;quot;as plain data&amp;quot; and the surprisingly benefits that emerge when we do. Programs that are built around the data they manage tend to be simpler, smaller, and significantly easier understand.&lt;p&gt;Java has changed radically over the last several years. It has picked up all kinds of new language features which support data oriented programming (records, pattern matching, `with` expressions, sum and product types). However, this is not a book about tools. No amount of studying a screw-driver will teach you how to build a house. This book focuses on house building. We&amp;#x27;ll pick out a plot of land, lay a foundation, and build upon it house that can weather any storm.&lt;p&gt;DoP is based around a very simple idea, and one people have been rediscovering since the dawn of computing, &amp;quot;representation is the essence of programming.&amp;quot; When we do a really good job of capturing the data in our domain, the rest of the system tends to fall into place in a way which can feel like it’s writing itself.&lt;p&gt;That&amp;#x27;s my elevator pitch! The book is currently in early access. I hope you check it out. I&amp;#x27;d love to hear your feedback.&lt;p&gt;You can get 50% off (thru October 9th) with code `mlkiehl`
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-java&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.manning.com&amp;#x2F;books&amp;#x2F;data-oriented-programming-in-j...&lt;/a&gt;</text></story><parent_chain><item><author>joshlemer</author><text>Given the strongly typed flavour of data oriented programming, I wonder if you have any thoughts on the &amp;quot;proliferation of types&amp;quot; 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&amp;#x27;s Maybe Not talk.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    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)
    
    ....&lt;/code&gt;&lt;/pre&gt;</text></item><item><author>goostavos</author><text>&amp;gt;Once I get two or more levels of nesting, I find it far too easy to get confused about which level I&amp;#x27;m on&lt;p&gt;Author here, I agree with you. I have the working memory of a small pigeon.&lt;p&gt;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&amp;#x27;ll always know what&amp;#x27;s shape it&amp;#x27;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.</text></item><item><author>geophile</author><text>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.&lt;p&gt;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&amp;#x27;m on, which is not helped by Python&amp;#x27;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.</text></item><item><author>mrbonner</author><text>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.</text></item><item><author>raju</author><text>Let me start by saying (as someone who has written a few technical books of his own)—Congratulations!&lt;p&gt;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!&lt;p&gt;I was exposed to &amp;quot;data oriented programming&amp;quot; thanks to Clojure—wherein maps&amp;#x2F;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.&lt;p&gt;Java&amp;#x27;s recent innovations certainly make this a lot easier, and I am glad someone is looking at propagating a much needed message.&lt;p&gt;I will take a look at the book, but I wish you the very best.</text></item></parent_chain><comment><author>kentosi</author><text>I haven&amp;#x27;t yet had the luxury to experiment with the latest version of Java, but this is one of the reasons why I wish Java introduced named parameters the say way kotlin and scala do.&lt;p&gt;Eg:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  data class Make(makeId: String, name: String)
  data class Model(modelId: String, name: String)

  data class Car(make: Make, model: Model, year: String, ...)
&lt;/code&gt;&lt;/pre&gt;
Now you can go ahead and order the params whichever way you wish so long as you&amp;#x27;re explicitly naming them:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  val v1 = Car(make = myMake1, model = myModel1, year = &amp;quot;2023&amp;quot;, ...)
  val v1 = Car(model = myModel1, make = myMake1, year = &amp;quot;2023&amp;quot;, ...)&lt;/code&gt;&lt;/pre&gt;</text></comment>