Monday, 11 March 2024 ------------------------ In the ninth chapter, we learn a little about 'essentalism', a way to model the world that is intuitive but has limitations that can get us stuck in a too simplistic understanding, preventing us from moving forward to a better understanding. From what I understood, essentialism is about seeing things as having an 'essence' that makes it that thing on its own. The main issue with this view is it can lead us to a dead end. If you can't find the essence within the thing, what really makes the thing, may only be found if one looks outside the thing, considering the environment it exists in, its relation to other things in its environment. That it may seem as its own thing but that it only exists as thing by an abstraction we make. I'd say it is a bit like viewing an object without considering how it's implemented in practice, or simplifying it. I'm drawing from my limited experience in programming, mainly Java. In Java, you can have an interface for some object type, let's say a list that can store instances of some object type. But this interface is just an abstraction. It only shows you the methods (functions) that the list has, like getting an element from the list, adding an element to the list, removing an element to the list. It hides or abstracts the implementation of how this is actually done. This is usually not a problem, but in certain scenarios this can result in unexpected behaviour that can also be hard to replicate because it only happens in specific scenarios during the program running. With lists, if you don't understand how the lists does its magic or the system the list is a part of, you may not realise a list (ArrayList) is not safe to use or won't work as expected if your program runs multiple threads, each modifying the list. Furthermore, you'll usually find that the implementation can be very unintuitive because it is implemented with consideration of the system it exists in and how it interacts with everything else in the system. Just in this context, all the layers of abstraction from binary to an interface in Java, there contains vast amount of stuff one must keep into consideration. But you also see that there's not something that makes a list a list except the abstract interface. A list can be implemented in all sorts of ways, and usually the best one is dependent on the context, how the list will be used such as if it's read or write heavy. Our brain models the world categorically, biased to see things that look the same seem more same, while also seeing things that look different, look even more different. There's nothing wrong with this, it's just important to be aware of it to avoid confusion. Just as how when you implement something in programming, you have to consider the function and context because you're working with constraints where you must consider what is most important to prioritise to fulfil it's goal as best as possible. There is a more formal model for distributed databases that shows this if you want a more clear example, called cap theorem (ong no cap). So instead of getting stuck in finding the 'essence' of an emotion like fear. Realise it's an abstraction first of all, and that the implementation may be way more unintuitive than you may think, that includes the model of construction. We just have to decide which model is more useful for us to move forward to get a better understanding and not be afraid of uncertainty at least when it comes to trying to get a better understanding, like in a scientific setting. For your practical life, I don't think there's anything wrong with using basic models to make life easier. It's better than just giving up completely because that'll give you no guidance. You should just not forget its purpose, guiding you. Don't conflate it with the ultimate truth or that's there's nothing more to it. You're not god. People that say they know they way, the word of god, are disrespectful to god in my humble opinion. (what god exactly is, is beyond my understanding, I'm just using that word to guide understanding, I'm not referring to any particular definition that has been made). This opens up interesting questions about with consideration of human constraints, we may function better with simpler models, as I said in an early writing, we must remember we experience life as humans. I think a model has to consider confusion and conflict. If your model keeps not working for you, it may be worth to do a little remodelling. My attempt at an analogy: Your attic is a mess. There's stuff all over the place. You're not sure what there is or where it is. To make sense of this, you put everything in labelled boxes. At first, everything goes in its own box. But it's still a mess, just a mess of boxes now. Instead, you get fewer boxes that are a bit bigger. Everything doesn't get its own box, but everything that seems to fit nicely together goes in the same box. Fewer boxes to traverse, yet everything can still be found by fitting box labels. Now you try to put everything into your neat boxes, but unfortunately, it still won't add up. Some boxes are near empty, some boxes are overfilled, and some stuff don't even fit in any box. You try again and again, different box labels, different box sizes. Eventually a compromise must be made. Either you must put what doesn't fit nicely together in the same box, or you must leave behind what there's not space for in your nicely fit boxes. Yesterday I was watching a youtube video about how in certain circumstances, you can't predict stuff with classical physics, but that with quantum physics there's also lots of uncertainties. But I saw a comment on the video with the phrase "There are no correct models. Only useful ones". I think that's a good way to summarise what I've been writing about here, whether the model is for scientific pursuit or a model for how to go about your life.