The big idea is that record types that have optional values (such as Maybe in Haskell) don't give you enough context on when, where, and how those values can be optional. Additionally, by placing things in buckets, the argument is that records and optional types are more brittle than the alternative, maps that can simply have missing keys for what would be optional. The imagery of a herd of sheep (map) versus compartments into which each sheep can go (records, Optional types, etc.) is brought up to illustrate a desire for more fluid engagement with information that may or may not exist or be needed, all of which is a description of a named aggregate of information we care about in context.
While I see the merit in his arguments, I believe his approach to data is "Clojure-like" or Lisp-like, in that it discourages explicit enumeration of all states and their possible configurations for the tradeoff of being able to sculpt these records. But, as a Haskell dev, I do not want to sculpt the records in the way he describes. I want to explicitly enumerate all the possibilities. This is, in my mind, a difference in cognitive preference. There is no right or wrong way and I think what he proposes is elegant. It is ultimately a matter of up front reasoning about the space compared with reaching a synthesis of the problem domain over time through wrestling with the problem itself. It is a statement about the efficacy of saying what can be known up front and to what extent, how much accuracy, and what utility.
I am about to launch a SaaS that pairs languages to these cognitive patterns as explicit understanding of such information can help bring together people who think similarly about information (team-building) while also opening up the possibility of expanding ones insights with alternative ideas and approaches (as his talk has done for me). The intent is to help hiring teams find devs that match their culture's programming and problem solving styles (whether that be reinforcing or doubling down on ways of thinking and acting).
While I see the merit in his arguments, I believe his approach to data is "Clojure-like" or Lisp-like, in that it discourages explicit enumeration of all states and their possible configurations for the tradeoff of being able to sculpt these records. But, as a Haskell dev, I do not want to sculpt the records in the way he describes. I want to explicitly enumerate all the possibilities. This is, in my mind, a difference in cognitive preference. There is no right or wrong way and I think what he proposes is elegant. It is ultimately a matter of up front reasoning about the space compared with reaching a synthesis of the problem domain over time through wrestling with the problem itself. It is a statement about the efficacy of saying what can be known up front and to what extent, how much accuracy, and what utility.
I am about to launch a SaaS that pairs languages to these cognitive patterns as explicit understanding of such information can help bring together people who think similarly about information (team-building) while also opening up the possibility of expanding ones insights with alternative ideas and approaches (as his talk has done for me). The intent is to help hiring teams find devs that match their culture's programming and problem solving styles (whether that be reinforcing or doubling down on ways of thinking and acting).