3 ms·

I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn. Totally a

I wrote an exercise once while I was teaching: "pure functional pacman". Really I did it to teach myself Redux, and it was a pretty fun way to learn. Totally agree with the article: sometimes functional is the right tool for the job, sometimes OOP. A more recent example: parsing USB descriptors in Rust. The parser would have been trivial and easy to understand if I could have multiple mutable references to nodes, but alas I kept fighting the borrow checker. I talked with a friend about why it was so hard, and he said "do it in a functional style". That made my borrow checker worries go away, but instead I have multiple "tree pivoters" that recursively descend through input trees while building output trees. It practically broke my brain and although it is pure, it's not nearly as readable or maintainable as one with mutation would have been.

marcan_42 6y ago
Off topic, but may I ask what USB stack you're working on? Because it might have a chance at being the first USB stack not full of exploitable bugs. (I've deliberately and accidentally triggered bugs in pretty much every mainstream USB stack; it's a sad state of affairs, mostly because USB is practically designed to include the maximum number of implementation pitfalls... but I'm sure you know this already)
- voodootrucker 6y ago
  I'm talking to a bunch of UVC webcams using https://docs.rs/rusb/0.6.4/rusb/ https://docs.rs/rusb/0.6.4/rusb/ for some conferencing software. So sadly no help for your (very valid) concerns.
dehrmann 6y ago
> sometimes OOP. I think OOP is taught somewhat wrong because people will dwell on contrived examples of inheritance when its real value as a paradigm is coupling state with functions. What we've learned from FP is immutability is easier to reason about, but when it isn't is when OOP shines because it gives you a sane way for managing state.
- voodootrucker 6y ago
  I _really_ struggled to not use contrived examples when teaching OOP. It was very hard because you don't really need it until your application becomes non-trivial so I see why all the college classes use cars & trucks or whatever. I think I ended up going with a Player API with tapes, records, CDs etc. Some could skip, others only fast-forward. I was still unhappy with it, but it was better than most examples. I like to point folks at writing an IntelliJ plugin. I find that some of the best architected OOP programs become nothing but a collection of plugin interfaces and base classes. But you really need to understand "is a" vs "has a", not burn your base class, let architecture emerge following the rule of 3, rather than quickly jumping on the wrong abstraction to fight duplication. Sandi Metz really says it better than I can: https://www.youtube.com/watch?v=8bZh5LMaSmE https://www.youtube.com/watch?v=8bZh5LMaSmE
  - catlifeonmars 6y ago
    If it helps, IMO inheritance is the least interesting feature of OOP. Programming with interfaces is a much more compelling story. A concrete example that is probably small enough to fit within an article or class is a 2d physics engine, where object positions, velocities and accelerations are updated in a loop.
- DangitBobby 6y ago
  Inheritance is valuable and gets a bad wrap, IMO. I just think about Django's `Model` class and how much time that's saved me and probably tens of thousands of other people. It doesn't even really seem to have any foot guns to speak of, it's just a great use of the abstraction to build up database models without mucking about in the stuff you wish was already written. The downside to them is that there is that the base class in the inheritance chain (BaseModel -> Model -> YourModel) has some magic that is difficult to reason about (the upside being the other side of that same token!). Thankfully, it's reliable and there's rare occasion to dive in. Maybe this is a me problem. I don't know how to make a nice abstraction layer like that without inheritance, so I think inheritance is sometimes the answer.
  - 6y ago

marcan_42 6y ago

Off topic, but may I ask what USB stack you're working on? Because it might have a chance at being the first USB stack not full of exploitable bugs. (I've deliberately and accidentally triggered bugs in pretty much every mainstream USB stack; it's a sad state of affairs, mostly because USB is practically designed to include the maximum number of implementation pitfalls... but I'm sure you know this already)

voodootrucker 6y ago
I'm talking to a bunch of UVC webcams using https://docs.rs/rusb/0.6.4/rusb/ https://docs.rs/rusb/0.6.4/rusb/ for some conferencing software. So sadly no help for your (very valid) concerns.

dehrmann 6y ago

> sometimes OOP. I think OOP is taught somewhat wrong because people will dwell on contrived examples of inheritance when its real value as a paradigm is coupling state with functions. What we've learned from FP is immutability is easier to reason about, but when it isn't is when OOP shines because it gives you a sane way for managing state.

voodootrucker 6y ago
I _really_ struggled to not use contrived examples when teaching OOP. It was very hard because you don't really need it until your application becomes non-trivial so I see why all the college classes use cars & trucks or whatever. I think I ended up going with a Player API with tapes, records, CDs etc. Some could skip, others only fast-forward. I was still unhappy with it, but it was better than most examples. I like to point folks at writing an IntelliJ plugin. I find that some of the best architected OOP programs become nothing but a collection of plugin interfaces and base classes. But you really need to understand "is a" vs "has a", not burn your base class, let architecture emerge following the rule of 3, rather than quickly jumping on the wrong abstraction to fight duplication. Sandi Metz really says it better than I can: https://www.youtube.com/watch?v=8bZh5LMaSmE https://www.youtube.com/watch?v=8bZh5LMaSmE
- catlifeonmars 6y ago
  If it helps, IMO inheritance is the least interesting feature of OOP. Programming with interfaces is a much more compelling story. A concrete example that is probably small enough to fit within an article or class is a 2d physics engine, where object positions, velocities and accelerations are updated in a loop.
DangitBobby 6y ago
Inheritance is valuable and gets a bad wrap, IMO. I just think about Django's `Model` class and how much time that's saved me and probably tens of thousands of other people. It doesn't even really seem to have any foot guns to speak of, it's just a great use of the abstraction to build up database models without mucking about in the stuff you wish was already written. The downside to them is that there is that the base class in the inheritance chain (BaseModel -> Model -> YourModel) has some magic that is difficult to reason about (the upside being the other side of that same token!). Thankfully, it's reliable and there's rare occasion to dive in. Maybe this is a me problem. I don't know how to make a nice abstraction layer like that without inheritance, so I think inheritance is sometimes the answer.
- 6y ago