4 ms·

So I had originally wanted to mock this article for a number of reasons: the fact that it doesn’t directly answer its own headline question, the fact that it sp

So I had originally wanted to mock this article for a number of reasons: the fact that it doesn’t directly answer its own headline question, the fact that it spends way more time talking about physics, the fact that it doesn’t connect “first principles thinking” with “the essence of the problem”, the fact that the title is phrased like a Zoolander joke.. > Is reality a collection of objects or a system of processes But when I read this phrase, something struck with me. I kind of hate that we’re originally taught OBJECT oriented programming, specifically that the name is “object-oriented”. I know that the ‘object’ in OOP and object as he is using the phrase above are not necessarily the same technical definition, nonetheless it took me far too long to understand that software engineering is not about the objects: its about the systems. OOP feels like a an awful misdirect as to where one should direct their time and attention in writing code. “You told me my code should be object oriented so I thought real hard about making sure I used objects!” I would far rather have a junior write one flawless function that DoesTheThing™ rather than a fleet of mis-organized objects that scatter the idea incorrectly. Why? Because DoesTheThingScript() can be more readily and easily refactored than ObjectOrientedMess™.

rektide 4y ago
Gilbert Simondon talks about change & individuation, with a term "allagmatic" or latter I think Yuk Hui re-dedubbed cosmotechnics. The are some lovely reflections on a similar duality, between systems and objects: Simondon reflects that reality is comprised of, depending on point of view, either structures (objects) undergoing operations to become new structures (s-o-s) or operations yielding new structures which in turn shift the system into new operations (o-s-o). In terms of code organization, i do think there's certainly a clarity to DoesTheThing. But as we evolve & change & begin to do different things, or as we have different ideas, there's more allure to shifting power from the script into the entities being scripted, to encompassing more capability & responsibility in the objects. Alas we often bungle up & confuse our object systems quickly- when we make bad picks in a bigger system, they stay with us, where as DoesTheThing will more than likely be replaced or become a cog in some other bigger script; it's faults & limitations stand less chance of becoming visible.
- raydiatian 4y ago
  > allagmatic > cosmotechnics Thanks for new favorite words.
discreteevent 4y ago
DoesTheThing is fine for a function. E.g. if TheThing is cosine(x) then that works. But most computer systems are not functions. They have some internal state. So it becomes DoesAThing. AThing may different every time depending on the internal state. This is neither an object nor a process in the articles terms. It's more like an object in OOP terms.
- raydiatian 4y ago
  Perhaps what I mean to convey here is that OOP (to my dumb newbie brain from N years ago) sounded like classes/objects were the hammer, everything else was a nail. The truth as I see it now is, I think, more that the patterns/problem statement are the hammer, and classes/objects are the nail. I spent a long time early on trying to map real-world objects to coded abstractions. In practice, at least as far as enterprise goes, it’s nothing of the sort: the objects we tend to create are DoThingClient, BrokerThingRepository, CreateThingFactory, HandleThingSevice, and then whatever STL & Framework you might build/ship with. Everything else might be a “class” out of restriction by the language, but they’re really just data records or procedures. I’m sure things might be different in game development, embedded, OS, etc. But object oriented programming feels like it doesn’t quite convey what we actually do as we trying to get a senior-level understanding of SE. Anyway, this is my hottake and it’s totally warped around my perspective
  - discreteevent 4y ago
    > the patterns/problem statement are the hammer, and classes/objects are the nail. Very good analogy. Matches my experience also.
menotyou 4y ago
With object orientation you can not even fry an egg because you can not prperly decide whether frying is a method of the egg, the pan or even the stove. Ist's a procedure which takes a piece of food, a pan and an oven and produces a fried egg.

rektide 4y ago

Gilbert Simondon talks about change & individuation, with a term "allagmatic" or latter I think Yuk Hui re-dedubbed cosmotechnics. The are some lovely reflections on a similar duality, between systems and objects: Simondon reflects that reality is comprised of, depending on point of view, either structures (objects) undergoing operations to become new structures (s-o-s) or operations yielding new structures which in turn shift the system into new operations (o-s-o). In terms of code organization, i do think there's certainly a clarity to DoesTheThing. But as we evolve & change & begin to do different things, or as we have different ideas, there's more allure to shifting power from the script into the entities being scripted, to encompassing more capability & responsibility in the objects. Alas we often bungle up & confuse our object systems quickly- when we make bad picks in a bigger system, they stay with us, where as DoesTheThing will more than likely be replaced or become a cog in some other bigger script; it's faults & limitations stand less chance of becoming visible.

raydiatian 4y ago
> allagmatic > cosmotechnics Thanks for new favorite words.

discreteevent 4y ago

DoesTheThing is fine for a function. E.g. if TheThing is cosine(x) then that works. But most computer systems are not functions. They have some internal state. So it becomes DoesAThing. AThing may different every time depending on the internal state. This is neither an object nor a process in the articles terms. It's more like an object in OOP terms.

raydiatian 4y ago
Perhaps what I mean to convey here is that OOP (to my dumb newbie brain from N years ago) sounded like classes/objects were the hammer, everything else was a nail. The truth as I see it now is, I think, more that the patterns/problem statement are the hammer, and classes/objects are the nail. I spent a long time early on trying to map real-world objects to coded abstractions. In practice, at least as far as enterprise goes, it’s nothing of the sort: the objects we tend to create are DoThingClient, BrokerThingRepository, CreateThingFactory, HandleThingSevice, and then whatever STL & Framework you might build/ship with. Everything else might be a “class” out of restriction by the language, but they’re really just data records or procedures. I’m sure things might be different in game development, embedded, OS, etc. But object oriented programming feels like it doesn’t quite convey what we actually do as we trying to get a senior-level understanding of SE. Anyway, this is my hottake and it’s totally warped around my perspective
- discreteevent 4y ago
  > the patterns/problem statement are the hammer, and classes/objects are the nail. Very good analogy. Matches my experience also.

menotyou 4y ago

With object orientation you can not even fry an egg because you can not prperly decide whether frying is a method of the egg, the pan or even the stove. Ist's a procedure which takes a piece of food, a pan and an oven and produces a fried egg.