3 ms·

This is a great comment. Thank you. I have had the opposite question from one posted to SE: What enlightenment will I attain when I can move beyond thinking o

by gwu78 13y ago

This is a great comment. Thank you. I have had the opposite question from one posted to SE: What enlightenment will I attain when I can move beyond thinking of every solution in programming as a FSM? I have never understood the obsession with higher level languages with objects, classes, methods, etc. I can't seem to think beyond lex, regular expressions and case statements. You comment is reassuring. Maybe I'm already emlightened. And I just don't know it.

lmm 13y ago
Encapsulation is what you're missing. OO programming only makes sense once you're working on a codebase too big to understand. I mean, I guess you could think of each object as its own FSM, but that's not particularly enlightening - in part because well designed objects don't have multiple possible states (rather, the state is captured in what they are. It's a hard notion to accept, like learning to use infinitesimals in mathematics - you've spent so long convincing yourself that this intuitive notion is wrong, and then suddenly you discover there's a way to make that intuitive notion correct after all, but you resist it because it seems like it's a messy, bad intuition). Yes, technically there are states to the whole system - but you need some way to factorize it into smaller systems if you're going to make any sense of it. There is a real enlightenment to be got from really understanding OO, and it's one that many supposedly good programmers seem never to reach. Keep seeking it.
- gwu78 13y ago
  "... only makes sense once you're working on a codebase too big to understand." My aim is to never reach this point. When I can no longer understand it, it's too big. That said, I will remain curious about OO.
  - lmm 13y ago
    No-one fully understands their programs; even if you understand all the code, few people understand the language implementation, fewer understand the underlying OS libraries, and I'm pretty sure no-one understands every level of the hardware (I've seen guys who were lead on some section of an Intel processor say they didn't understand the whole thing). Now sure, you can say that when a single code project becomes too big to understand then it should be split up into a bunch of libraries, or a bunch of independent services. Which is true up to a point. But I find there's value in having a more granular continuum of decoupling scales - method, class, package, module, library, service - which OO makes possible. And I'd argue that many of these kind of libraries and services - particularly the REST style - are inherently OO.
    - gwu78 13y ago
      I more drawn to assembly languages than OO languages. Less granules to deal with. :) I welcome limitation. It is what fuels my creativity. I make no attempt to persuade others to mimic my personal tastes.

by gwu78 13y ago

lmm 13y ago

Encapsulation is what you're missing. OO programming only makes sense once you're working on a codebase too big to understand. I mean, I guess you could think of each object as its own FSM, but that's not particularly enlightening - in part because well designed objects don't have multiple possible states (rather, the state is captured in what they are. It's a hard notion to accept, like learning to use infinitesimals in mathematics - you've spent so long convincing yourself that this intuitive notion is wrong, and then suddenly you discover there's a way to make that intuitive notion correct after all, but you resist it because it seems like it's a messy, bad intuition). Yes, technically there are states to the whole system - but you need some way to factorize it into smaller systems if you're going to make any sense of it. There is a real enlightenment to be got from really understanding OO, and it's one that many supposedly good programmers seem never to reach. Keep seeking it.

gwu78 13y ago
"... only makes sense once you're working on a codebase too big to understand." My aim is to never reach this point. When I can no longer understand it, it's too big. That said, I will remain curious about OO.
- lmm 13y ago
  No-one fully understands their programs; even if you understand all the code, few people understand the language implementation, fewer understand the underlying OS libraries, and I'm pretty sure no-one understands every level of the hardware (I've seen guys who were lead on some section of an Intel processor say they didn't understand the whole thing). Now sure, you can say that when a single code project becomes too big to understand then it should be split up into a bunch of libraries, or a bunch of independent services. Which is true up to a point. But I find there's value in having a more granular continuum of decoupling scales - method, class, package, module, library, service - which OO makes possible. And I'd argue that many of these kind of libraries and services - particularly the REST style - are inherently OO.
  - gwu78 13y ago
    I more drawn to assembly languages than OO languages. Less granules to deal with. :) I welcome limitation. It is what fuels my creativity. I make no attempt to persuade others to mimic my personal tastes.