7 ms·

I remember him as well, he didn't understand OO well enough to critique it so very little of what he said had any actual value. "Spirited" is a nice way to put

I remember him as well, he didn't understand OO well enough to critique it so very little of what he said had any actual value. "Spirited" is a nice way to put it, a bit colored by nostalgia though. His idea of programming is a big ball of procedural mud over a relational database where every task is a hand written sql query/loop over result set, fucking terrible.

barrkel 10y ago
Many integrated CRUD apps are best written as procedures (call them REST endpoints if you prefer) that (ultimately) use SQL queries to update a store of facts. In a heterogeneous world, the idea that you have an authoritative model defined in any one language, that merely uses the database for persistence, is untenable. Objects with hidden state are a poor way to model facts about the world. Having been a follower of OOP since the early 90s until my disillusionment in the mid 00s, to my mind only a handful of problem domains are best modelled as interacting graphs of mutable objects, and the set grows smaller over time. I'm increasingly unconvinced that procedures+SQL done well is inferior to the average developer's OOP code. And if OOP hasn't delivered that kind of mental leverage, then it's mostly a sham. (I should add that I'm far more inclined to try and model things functionally, with functions that turn input into a set of logical diffs rather than straight-up database modifications, than actually advocate all-out procedural programming with raw SQL. But even raw SQL is superior to effectively performing complex queries in a non-relational language, where the indexes are built by hand and passed around.)
- naasking 10y ago
  > only a handful of problem domains are best modelled as interacting graphs of mutable objects, and the set grows smaller over time. Indeed, the CRUD service itself is an OO interface (send it GET/POST messages to an endpoint). How that's implemented behind that need not be OO.
  - barrkel 10y ago
    And arguably that's the biggest problem with the modern web: the non-idempotence of GET in a world with PUT (and POST).
  - digi_owl 10y ago
    Would that make C functions OO?
- gnaritas 10y ago
  Sure, but the world is bigger than CRUD apps, and even in CRUD apps, object mapping is more productive than hand written SQL slinging result sets around in procedural code. In particular the ease at which OO enabled pluggable programs is invaluable in customizing in different ways for different clients or aggregating data from multiple sources. OO isn't about modeling facts about the world, it's about modelling behavior; objects aren't just structs with some data. > But even raw SQL is superior to effectively performing complex queries in a non-relational language, where the indexes are built by hand and passed around. I think that's a bit of a strawman, that's not what OO is. > In a heterogeneous world, the idea that you have an authoritative model defined in any one language, that merely uses the database for persistence, is untenable. That's not what OO is either.
  - barrkel 10y ago
    CRUD apps are mostly about synchronizing a set of facts about the world with the world itself. Re complex queries in a non-relational language: I know that's not what OO is, but if you're trying to perform a map / filter / aggregate operation across several different collections (sometimes these kinds of things need to be done!), OO doesn't give you many tools, and the tools you can build are usually poor versions of what's available in functional languages, which are themselves less specialized and less declarative than relational languages. If you can represent your problem as a map/filter/aggregate operation, it (a) becomes more testable, (b) more parallelizable in both large and small and (c) more composable. I happen to think it ends up being easier to read, write and reason about too. So I try hard to make my problems look like this, because I know the tools in that area are very strong. Objects being more than structs with immutable data is exactly what's wrong with them. OO encourages you to reason about behaviour in terms of invariants: what's true before vs what's true after, or what is always true for an instance. I think that's strictly inferior to reasoning by transformation: what is the input vs what is the output. In particular, I think functional transformation is more composable than invariants. I'd feel happier about OO and its implicit invariants if they were made more explicit, and more than just like Eiffel: it needs to be in the type system, if possible.
    - gnaritas 10y ago
- notduncansmith 10y ago
  Hey man, accidentally downvoted this comment but I agree heartily. In fact, if you're interested in the approach you describe at the end of your comments, you should read about "event sourcing", CQRS, Redux, Apache Samza, Elm, and re-frame.
- digi_owl 10y ago
  IMO, OOP sounds nice but frankly we humans work in procedural ways. Everything from farming on up can be described as "first we do X then we do Y".
  - gnaritas 10y ago
    That something can be described in a procedural manner does not imply we humans work that way, nor does it preclude the fact the those same things can be described in other manners as well. When you interact with other people, you do it the OO way, you send them a message and they either act on it or not depending on their own internal state with different people able to respond differently to the same set of messages; I can just as easily claim we humans work in OO ways. Beyond that, it's easier to describe a sequence of steps in OO where the implementation details can be hidden and swapped out with different implementations than in procedures where the logic and implementation are all mixed together and tightly coupled.
    - digi_owl 10y ago
      That seems like a very different definition of OO than i am used to seeing.
      - gnaritas 10y ago
        What definition are you used to seeing? I'm a Smalltalk'er, OO has been since its creation, about objects communicating via messages while hiding their implementation details so different implementations can be swapped in, i.e. late binding, polymorphism, and encapsulation, that's rather the entire point of OO.
        digi_owl 10y ago
        C++ and similar.
        gnaritas 10y ago

barrkel 10y ago

Many integrated CRUD apps are best written as procedures (call them REST endpoints if you prefer) that (ultimately) use SQL queries to update a store of facts. In a heterogeneous world, the idea that you have an authoritative model defined in any one language, that merely uses the database for persistence, is untenable. Objects with hidden state are a poor way to model facts about the world. Having been a follower of OOP since the early 90s until my disillusionment in the mid 00s, to my mind only a handful of problem domains are best modelled as interacting graphs of mutable objects, and the set grows smaller over time. I'm increasingly unconvinced that procedures+SQL done well is inferior to the average developer's OOP code. And if OOP hasn't delivered that kind of mental leverage, then it's mostly a sham. (I should add that I'm far more inclined to try and model things functionally, with functions that turn input into a set of logical diffs rather than straight-up database modifications, than actually advocate all-out procedural programming with raw SQL. But even raw SQL is superior to effectively performing complex queries in a non-relational language, where the indexes are built by hand and passed around.)

naasking 10y ago
> only a handful of problem domains are best modelled as interacting graphs of mutable objects, and the set grows smaller over time. Indeed, the CRUD service itself is an OO interface (send it GET/POST messages to an endpoint). How that's implemented behind that need not be OO.
- barrkel 10y ago
  And arguably that's the biggest problem with the modern web: the non-idempotence of GET in a world with PUT (and POST).
- digi_owl 10y ago
  Would that make C functions OO?
gnaritas 10y ago
Sure, but the world is bigger than CRUD apps, and even in CRUD apps, object mapping is more productive than hand written SQL slinging result sets around in procedural code. In particular the ease at which OO enabled pluggable programs is invaluable in customizing in different ways for different clients or aggregating data from multiple sources. OO isn't about modeling facts about the world, it's about modelling behavior; objects aren't just structs with some data. > But even raw SQL is superior to effectively performing complex queries in a non-relational language, where the indexes are built by hand and passed around. I think that's a bit of a strawman, that's not what OO is. > In a heterogeneous world, the idea that you have an authoritative model defined in any one language, that merely uses the database for persistence, is untenable. That's not what OO is either.
- barrkel 10y ago
  CRUD apps are mostly about synchronizing a set of facts about the world with the world itself. Re complex queries in a non-relational language: I know that's not what OO is, but if you're trying to perform a map / filter / aggregate operation across several different collections (sometimes these kinds of things need to be done!), OO doesn't give you many tools, and the tools you can build are usually poor versions of what's available in functional languages, which are themselves less specialized and less declarative than relational languages. If you can represent your problem as a map/filter/aggregate operation, it (a) becomes more testable, (b) more parallelizable in both large and small and (c) more composable. I happen to think it ends up being easier to read, write and reason about too. So I try hard to make my problems look like this, because I know the tools in that area are very strong. Objects being more than structs with immutable data is exactly what's wrong with them. OO encourages you to reason about behaviour in terms of invariants: what's true before vs what's true after, or what is always true for an instance. I think that's strictly inferior to reasoning by transformation: what is the input vs what is the output. In particular, I think functional transformation is more composable than invariants. I'd feel happier about OO and its implicit invariants if they were made more explicit, and more than just like Eiffel: it needs to be in the type system, if possible.
  - gnaritas 10y ago
notduncansmith 10y ago
Hey man, accidentally downvoted this comment but I agree heartily. In fact, if you're interested in the approach you describe at the end of your comments, you should read about "event sourcing", CQRS, Redux, Apache Samza, Elm, and re-frame.
digi_owl 10y ago
IMO, OOP sounds nice but frankly we humans work in procedural ways. Everything from farming on up can be described as "first we do X then we do Y".
- gnaritas 10y ago
  That something can be described in a procedural manner does not imply we humans work that way, nor does it preclude the fact the those same things can be described in other manners as well. When you interact with other people, you do it the OO way, you send them a message and they either act on it or not depending on their own internal state with different people able to respond differently to the same set of messages; I can just as easily claim we humans work in OO ways. Beyond that, it's easier to describe a sequence of steps in OO where the implementation details can be hidden and swapped out with different implementations than in procedures where the logic and implementation are all mixed together and tightly coupled.
  - digi_owl 10y ago
    That seems like a very different definition of OO than i am used to seeing.
    - gnaritas 10y ago
      What definition are you used to seeing? I'm a Smalltalk'er, OO has been since its creation, about objects communicating via messages while hiding their implementation details so different implementations can be swapped in, i.e. late binding, polymorphism, and encapsulation, that's rather the entire point of OO.
      - digi_owl 10y ago
        C++ and similar.
        gnaritas 10y ago