7 ms·

My first programming teacher emphasized that this at-the-time-newfangled "object-oriented" programming was only a way of organizing the code, you still had the

My first programming teacher emphasized that this at-the-time-newfangled "object-oriented" programming was only a way of organizing the code, you still had the same data and functions. Use classes, don't use classes. It doesn't matter.

kragen 7y ago
I feel like dynamically-dispatched open recursion gives you a level of flexibility that you can't get in, say, Pascal — you need first-class function pointers if you don't have virtual functions. BTW, I finally responded to your comment from the other day; sorry about the delay!
- carapace 7y ago
  Well, Oberon had language-level OOP-- records with methods --which is what my teacher was talking about as just a way to arrange the same data and functions, but the OS also had runtime dynamic message dispatch OOP built on top of but not intrinsically requiring the language-level OOP. I suspect you could implement that in Pascal and make all of Hewitt's Actors model with it. > BTW, I finally responded to your comment from the other day; sorry about the delay! Cheers! I'll go check that out :-)
  - kragen 7y ago
    Yeah, the Oberon language added function pointers (I don't remember if those were in Modula-2), and the Oberon OS used that form of language-level OOP to implement its runtime dynamic message dispatch OOP. You can't implement that in Pascal because Pascal doesn't allow you to store function pointers in records (because they might be nested functions, with all that implies). So in Pascal the best you can do is write a switch function for each function pointer type (signature) and use an enumerated type or equivalent to dispatch calls.
    - carapace 7y ago
      > So in Pascal the best you can do is write a switch function for each function pointer type (signature) and use an enumerated type or equivalent to dispatch calls. Yeah, you would have to spell it out and you couldn't do compile-time optimizations, but you could get all the dynamic flexibility you need? Really, what I was saying above is just that if your problem is easier to describe as a bunch of interacting "objects" (like a game or a factory sim) then use OOP, but if it's easier to describe as a set of functions and data structures then don't use OOP. :-)
      - kragen 7y ago
        Well, sort of; I mean clearly Pascal is a Turing-complete programming language, so it provides you all the flexibility you need. But if you write a switch function for each function pointer type, it means that local changes in an OO language, or in C, map to global changes in the Pascal translation of it, so I'd argue that the OO language, or C, is more expressive in a fundamentally meaningful way. (Actually existing implementations of Pascal usually added a function pointer type of some kind, but I'm talking about the language standard.) I think the crucial question is whether the objects have different behavior. If all the objects implement a particular operation in the same way, or in one of two or three ways, there's no advantage to OOP. If their behavior varies in an open, expandable way — like, you might have an arbitrarily large number of monsters whose movement strategy varies arbitrarily — then OOP, or function pointers, can be helpful. If their behavior needs to vary in orthogonal and arbitrarily combinable ways, OOP may not be expressive enough, and maybe you should look at an entity-component-system architecture.
        carapace 7y ago
        That's basically what the Oberon OS messaging system did, it was a little clunky but it worked. The Gadgets widgets system is still my favorite after all these years. It was like OLE but good. I agree, if your code doesn't need objects, there's no advantage to OOP. and ECS is like extra-OOP. :-) (I replied to your reply in the other thread, BTW.)
kazinator 7y ago
You may still have the same data and functions, but you don't have the same number of case/switch statements. ;)

kragen 7y ago

I feel like dynamically-dispatched open recursion gives you a level of flexibility that you can't get in, say, Pascal — you need first-class function pointers if you don't have virtual functions. BTW, I finally responded to your comment from the other day; sorry about the delay!

carapace 7y ago
Well, Oberon had language-level OOP-- records with methods --which is what my teacher was talking about as just a way to arrange the same data and functions, but the OS also had runtime dynamic message dispatch OOP built on top of but not intrinsically requiring the language-level OOP. I suspect you could implement that in Pascal and make all of Hewitt's Actors model with it. > BTW, I finally responded to your comment from the other day; sorry about the delay! Cheers! I'll go check that out :-)
- kragen 7y ago
  Yeah, the Oberon language added function pointers (I don't remember if those were in Modula-2), and the Oberon OS used that form of language-level OOP to implement its runtime dynamic message dispatch OOP. You can't implement that in Pascal because Pascal doesn't allow you to store function pointers in records (because they might be nested functions, with all that implies). So in Pascal the best you can do is write a switch function for each function pointer type (signature) and use an enumerated type or equivalent to dispatch calls.
  - carapace 7y ago
    > So in Pascal the best you can do is write a switch function for each function pointer type (signature) and use an enumerated type or equivalent to dispatch calls. Yeah, you would have to spell it out and you couldn't do compile-time optimizations, but you could get all the dynamic flexibility you need? Really, what I was saying above is just that if your problem is easier to describe as a bunch of interacting "objects" (like a game or a factory sim) then use OOP, but if it's easier to describe as a set of functions and data structures then don't use OOP. :-)
    - kragen 7y ago
      Well, sort of; I mean clearly Pascal is a Turing-complete programming language, so it provides you all the flexibility you need. But if you write a switch function for each function pointer type, it means that local changes in an OO language, or in C, map to global changes in the Pascal translation of it, so I'd argue that the OO language, or C, is more expressive in a fundamentally meaningful way. (Actually existing implementations of Pascal usually added a function pointer type of some kind, but I'm talking about the language standard.) I think the crucial question is whether the objects have different behavior. If all the objects implement a particular operation in the same way, or in one of two or three ways, there's no advantage to OOP. If their behavior varies in an open, expandable way — like, you might have an arbitrarily large number of monsters whose movement strategy varies arbitrarily — then OOP, or function pointers, can be helpful. If their behavior needs to vary in orthogonal and arbitrarily combinable ways, OOP may not be expressive enough, and maybe you should look at an entity-component-system architecture.
      - carapace 7y ago
        That's basically what the Oberon OS messaging system did, it was a little clunky but it worked. The Gadgets widgets system is still my favorite after all these years. It was like OLE but good. I agree, if your code doesn't need objects, there's no advantage to OOP. and ECS is like extra-OOP. :-) (I replied to your reply in the other thread, BTW.)

kazinator 7y ago

You may still have the same data and functions, but you don't have the same number of case/switch statements. ;)