Clojurians Log v2

My experience have been the same actually, and agree completely with him. At the start of my career it was all about objects, and boundaries (like the composition over inheritance, SOLID, etc). And I always felt that what I was writing was way more than what I needed. Now I just write the code that do the job, and if I feel there's a boundary I'd like to create, I'd do it there and then. Which was pretty much his message.

I caught that too. @santiago.cabrera.silv what did you take away from that talk?

I think the talk is about empathy for our users over ourselves. Right at the start, casey demonstrates that choice when he contrasts where to cut the abstraction boundaries.

Also, i bet, i guess...he missed a key element of why sketch pad probably (i know nothing beyond what he said about it) worked so well. It probably only worked so well on that machine for its creator -_-.

@santiago.cabrera.silv I didn't really take away "write only what you need" or that objects, boundaries and inheritance are wrong. I think by-and-large his entire talk was circling that the reasons why something happened (why language authors added constructs) are not what people, even the original authors themselves later, say are the reasons. So, to your point, it's better to trust what your eyes can actually see, then get swept up in a past or future that might never happen. In that light, what i said earlier, is that having empathy for your users, putting yourself, in their shoes, is all about building ways to create shoes, not so that we the developers can enjoy the process of making shoes. Objects, often used, to model the domain (e.g shoes) often make it easy to conflate the user experience with the building experence, because they put in easy reach the notion of building a "shoe", e.g the class name shoe, which then stands in as a false replacement for the harder work of learning to talk to hardware to create a digital pipeline for delivering useful information about shoes.

Oh no, completely agree on the message of the history of OOP and how it actually unfolded. He mentioned this part of not doing an abstraction boundary that applies everywhere, but one that fits. Using OOP is too constrained, making some trivial things take too much effort to implement, as in the sketchpad demo the magic was in part the ability to see everything in the ring structure.