5 ms·

> It’s typical to listen to this stream of events and use chained if-else statements to determine an action based on the type of the events that occur. You'd t

> It’s typical to listen to this stream of events and use chained if-else statements to determine an action based on the type of the events that occur. You'd think something like directory watching would have a clear set of events that would make nice objects with consistent meanings, but in my experience file watching gets crazy complicated, and can have all sorts of edge cases. Just take a looked here for all the various edge cases that crop up: https://github.com/paulmillr/chokidar/issues https://github.com/paulmillr/chokidar/issues Then you have linux, windows, macos, and maybe you want to abstract over some underlying implementation like chokidar vs fb/watchman vs webpack/watchpack. Every new OS release could also cause things to change. A big leaky abstraction. So usually its going to be a bunch of if-else statements hacked together to get around edge cases, and have to be revisited later on. Any attempt to abstract this into objects, just obfuscates things. And OO forces you to name things, when in fact they might be un-nameable. `FileSystemModifyEventExceptWhenXAndYAndSometimesZ`. The behavior might rely on a series of events together, so the object hierarchy must be re-worked. OO has this rosy idea that we just have to come up with the perfect hierarchy, but things change in unexpected ways, and everything must have a descriptive noun.

the_gipsy 3y ago
The hierarchy always looks nice on the whiteboard but always breaks down as soon as you start to write it out in code.
taeric 3y ago
I've long thought it was less OO that was problematic, and more the idea that you can make a taxonomy that covered your entire problem domain. Worse, people seem to get caught up in the taxonomy for the sake of the taxonomy.
- tempodox 3y ago
  The thing is that OO forces taxonomy on you, especially if you have to deal with lots of inheritance.
  - taeric 3y ago
    It doesn't have to, though, if you are willing to not try and encode the world. Type systems, in general, seem to hit the same problem. If not, why? Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. You can have prescriptive interfaces that say what all has to happen for some work, but that should be much tighter in how it is put together.
    - coldtea 3y ago
      >Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. In that case you're just doing encapsulation with extra steps.
      - taeric 3y ago
        I'm not sure I follow? Any chance I can get you to expand on that? By descriptive, I'm less worried about hiding things. Though, yes, that is certainly a hallmark of how people talk about OO. I mainly don't like getting into debates about where in an inheritance tree something would go. Even if I do think there are values in small hierarchies. The most bang for buck is when they help someone implement a new part of the system. The last bang for the buck is when you are doing a lot of coding just to keep an inheritance tree looking a certain way.
        coldtea 3y ago
        >I'm not sure I follow? Any chance I can get you to expand on that? I mean, if you're trying to avoid hierarchies or keeping them small (like, say 2 levels most), then what are you using from the OO paradigm, except using classes as some kind of a bundle for related methods and for encapsulation? I'm not saying hierarchies are good or OO is good. Just that OO-while-avoiding-hierarchies doesn't seem worth to be a paradigm. Might as well ditch OO altogether, there are other ways to get the things you're keeping from OO then (e.g. Rust or Go style).
- coldtea 3y ago
  Well, OO (as practiced, not what Alan Kay had in mind) is all about making a taxonomy. And the real problem I think is not all domains map to hierarchical relationships. Often it's forced, like trying to force push a square peg in a round hole.
  - taeric 3y ago
    I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. Both ideas can be great, but I push more for both of them to be used in modeling the system. If there are different sections with "agency" in your system model, OO can make a ton of sense to work with those parts. If you have data getting passed around and worked with a lot, FP makes a ton of sense.
    - coldtea 3y ago
      >I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. I think it's not the same, because a taxonomy is a thing with limited descriptive power, and ultimately leading into a more or less arbitrary mapping, forced upon one's program design. Whereas "building your own algebra over the data in your system" has unlimited descriptive power, and is an abstraction over anything we do when we process data in a program. So, if we take "going to places" as a metaphor for programming, the first is like giving you the laws of motion and the ability to move in 4 dimensions as a tool (algebra), and the other is like telling you "you need to use a truck to travel, regardless of if you're going from LA to San Siego, from the bedroom to the WC, or from one floor to another" (OO).
      - taeric 3y ago
        Apologies, you seem to think I'm throwing them both under a lot of the same bus. That was not my full intent, and I will gladly cede that academia pushed OO far harder and to worse results than many functional things were pushed. That said, I think you are giving "algebras of data types" a bit too much credit here. The vast majority of the coding that is done will not be made better by elaborate ways of coding things above and beyond a relational language. Having an algebra is a happy convenience when it works. But I have been bitten by far too many failed attempts at making them work to think it is "unlimited descriptive power."
munificent 3y ago
For what it's worth, I've written plenty of code using file watching. I did a build system that needed to watch the file system to pick up file changes. You're absolutely right that file watching gets really hairy really fast. Sometimes you won't get events for files. Renaming directories can make things get all kinds of weird. Sometimes you'll get a flurry of updates for the same file and you need to debounce. It's a mess. But the actual atomic primitive events themselves I've found to be fairly simple. It's basically just write, delete, and rename. I think modeling that as a sum type of a sealed class hierarchy works fine. Most of the problems are a level above where the set of events is hard to parse meaningfully.
coldtea 3y ago
Directory watching would be more of a "finite state machine" kind of handling than "reacting to a set of possible fs events" handling.

the_gipsy 3y ago

The hierarchy always looks nice on the whiteboard but always breaks down as soon as you start to write it out in code.

taeric 3y ago

I've long thought it was less OO that was problematic, and more the idea that you can make a taxonomy that covered your entire problem domain. Worse, people seem to get caught up in the taxonomy for the sake of the taxonomy.

tempodox 3y ago
The thing is that OO forces taxonomy on you, especially if you have to deal with lots of inheritance.
- taeric 3y ago
  It doesn't have to, though, if you are willing to not try and encode the world. Type systems, in general, seem to hit the same problem. If not, why? Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. You can have prescriptive interfaces that say what all has to happen for some work, but that should be much tighter in how it is put together.
  - coldtea 3y ago
    >Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. In that case you're just doing encapsulation with extra steps.
    - taeric 3y ago
      I'm not sure I follow? Any chance I can get you to expand on that? By descriptive, I'm less worried about hiding things. Though, yes, that is certainly a hallmark of how people talk about OO. I mainly don't like getting into debates about where in an inheritance tree something would go. Even if I do think there are values in small hierarchies. The most bang for buck is when they help someone implement a new part of the system. The last bang for the buck is when you are doing a lot of coding just to keep an inheritance tree looking a certain way.
      - coldtea 3y ago
        >I'm not sure I follow? Any chance I can get you to expand on that? I mean, if you're trying to avoid hierarchies or keeping them small (like, say 2 levels most), then what are you using from the OO paradigm, except using classes as some kind of a bundle for related methods and for encapsulation? I'm not saying hierarchies are good or OO is good. Just that OO-while-avoiding-hierarchies doesn't seem worth to be a paradigm. Might as well ditch OO altogether, there are other ways to get the things you're keeping from OO then (e.g. Rust or Go style).
coldtea 3y ago
Well, OO (as practiced, not what Alan Kay had in mind) is all about making a taxonomy. And the real problem I think is not all domains map to hierarchical relationships. Often it's forced, like trying to force push a square peg in a round hole.
- taeric 3y ago
  I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. Both ideas can be great, but I push more for both of them to be used in modeling the system. If there are different sections with "agency" in your system model, OO can make a ton of sense to work with those parts. If you have data getting passed around and worked with a lot, FP makes a ton of sense.
  - coldtea 3y ago
    >I mean, yes, but this is like complaining that so much of functional programming as pushed by strangers on the internet is about building your own algebra over the data in your system. I think it's not the same, because a taxonomy is a thing with limited descriptive power, and ultimately leading into a more or less arbitrary mapping, forced upon one's program design. Whereas "building your own algebra over the data in your system" has unlimited descriptive power, and is an abstraction over anything we do when we process data in a program. So, if we take "going to places" as a metaphor for programming, the first is like giving you the laws of motion and the ability to move in 4 dimensions as a tool (algebra), and the other is like telling you "you need to use a truck to travel, regardless of if you're going from LA to San Siego, from the bedroom to the WC, or from one floor to another" (OO).
    - taeric 3y ago
      Apologies, you seem to think I'm throwing them both under a lot of the same bus. That was not my full intent, and I will gladly cede that academia pushed OO far harder and to worse results than many functional things were pushed. That said, I think you are giving "algebras of data types" a bit too much credit here. The vast majority of the coding that is done will not be made better by elaborate ways of coding things above and beyond a relational language. Having an algebra is a happy convenience when it works. But I have been bitten by far too many failed attempts at making them work to think it is "unlimited descriptive power."

munificent 3y ago

For what it's worth, I've written plenty of code using file watching. I did a build system that needed to watch the file system to pick up file changes. You're absolutely right that file watching gets really hairy really fast. Sometimes you won't get events for files. Renaming directories can make things get all kinds of weird. Sometimes you'll get a flurry of updates for the same file and you need to debounce. It's a mess. But the actual atomic primitive events themselves I've found to be fairly simple. It's basically just write, delete, and rename. I think modeling that as a sum type of a sealed class hierarchy works fine. Most of the problems are a level above where the set of events is hard to parse meaningfully.

coldtea 3y ago

Directory watching would be more of a "finite state machine" kind of handling than "reacting to a set of possible fs events" handling.