3 ms·

> I tend to mentally divide code into roughly two types: "computational" and "plumbing". I agree with this and would go even further. Divide your code into "s

> I tend to mentally divide code into roughly two types: "computational" and "plumbing". I agree with this and would go even further. Divide your code into "stateless" functional code and "stateful" objects code. Original OO was encapsulating things like device drivers that did I/O--it didn't represent data. If you don't interleave your stateless business logic with your stateful persistence, it's easy to mock "objects" that do the plumbing, and all the meat of the program is unit tests. Fwiw, the DI model (Guice, Spring, etc.) in modern Java/Scala shops closely hews to this, even if people don't mentally categorize it as such.

danans 6y ago
> Divide your code into "stateless" functional code and "stateful" objects code. IINM you are basically referring to the difference between static and instance methods in languages like C++ and Java. Putting code that neither reads nor writes the object state and instance methods is a common mistake made in both those languages. That said, both stateful and stateless code are good candidates for unit testing, especially when the code under test is a state machine, rather then just a data encapsulation mechanism.
- abernard1 6y ago
  Nah brah. (I'm gonna say "brah" because I'm feeling especially salty) Your _program_ should have the flow of a function. At the architectural level, who-the-ef cares about about static vs instance methods in Java (I say as a person with 23 years of Java experience.) It has nothing to do with languages. You can do this in any language you want. You want to have your inputs go through a process where you have (1) INPUT state transfer, (2) some computation F(INPUT), (3) some output and state transfer, or RESULT = F(INPUT). If you do not have (1) or (3)--I hate to break it to you--but all your program does is burn CPU. If you don't have (2), your program does nothing at all. The key thing with scalable systems is they manage complexity well. If you're at the level where you're worried about "static or instance methods", you're not dealing with how data changes in large systems at all. Those words are at the level of state within a language. You need to optimize at the global systems level.
  - danans 6y ago
    > At the architectural level, who-the-ef cares about about state vs instances methods in Java Who-the-ef should care is anyone who has to implement or maintain the code. After all, the debate at hand is what is worth unit testing, which very much concerns the programming language and the actual implementation. Don't know about you, but I both architect the system and write the code. > If you do not have (1) or (3)--I hate to break it to you--but all your program does is burn CPU. I haven't written production code that doesn't have (1) or (3) in my 25 years of programming, so not sure who you are talking to here. > If you're at the level where you're worried about "static or instance methods", you're not dealing with how data changes in large systems at all. Those words are at the level of state within a language. You have to tend to this stuff at both the generic data processing and language level. Using a given language's constructs for differentiating between stateful and stateless code is an important part of making the code document itself. Coding style matters.
    - abernard1 6y ago
      > Coding style matters. It. does. not. If it did, PHP wouldn't be running half the world. Structure and systems matter.
      - danans 6y ago
        > It. does. not. OK 'brah', whatever works for you! > If it did, PHP wouldn't be running half the world PHP has a style guide, and there is such a thing as clean, readable PHP code. https://www.php-fig.org/psr/psr-1/ https://www.php-fig.org/psr/psr-1/ I bet massive scale PHP based apps (like you know, Facebook) probably enforce style in their codebase.

danans 6y ago

> Divide your code into "stateless" functional code and "stateful" objects code. IINM you are basically referring to the difference between static and instance methods in languages like C++ and Java. Putting code that neither reads nor writes the object state and instance methods is a common mistake made in both those languages. That said, both stateful and stateless code are good candidates for unit testing, especially when the code under test is a state machine, rather then just a data encapsulation mechanism.

abernard1 6y ago
Nah brah. (I'm gonna say "brah" because I'm feeling especially salty) Your _program_ should have the flow of a function. At the architectural level, who-the-ef cares about about static vs instance methods in Java (I say as a person with 23 years of Java experience.) It has nothing to do with languages. You can do this in any language you want. You want to have your inputs go through a process where you have (1) INPUT state transfer, (2) some computation F(INPUT), (3) some output and state transfer, or RESULT = F(INPUT). If you do not have (1) or (3)--I hate to break it to you--but all your program does is burn CPU. If you don't have (2), your program does nothing at all. The key thing with scalable systems is they manage complexity well. If you're at the level where you're worried about "static or instance methods", you're not dealing with how data changes in large systems at all. Those words are at the level of state within a language. You need to optimize at the global systems level.
- danans 6y ago
  > At the architectural level, who-the-ef cares about about state vs instances methods in Java Who-the-ef should care is anyone who has to implement or maintain the code. After all, the debate at hand is what is worth unit testing, which very much concerns the programming language and the actual implementation. Don't know about you, but I both architect the system and write the code. > If you do not have (1) or (3)--I hate to break it to you--but all your program does is burn CPU. I haven't written production code that doesn't have (1) or (3) in my 25 years of programming, so not sure who you are talking to here. > If you're at the level where you're worried about "static or instance methods", you're not dealing with how data changes in large systems at all. Those words are at the level of state within a language. You have to tend to this stuff at both the generic data processing and language level. Using a given language's constructs for differentiating between stateful and stateless code is an important part of making the code document itself. Coding style matters.
  - abernard1 6y ago
    > Coding style matters. It. does. not. If it did, PHP wouldn't be running half the world. Structure and systems matter.
    - danans 6y ago
      > It. does. not. OK 'brah', whatever works for you! > If it did, PHP wouldn't be running half the world PHP has a style guide, and there is such a thing as clean, readable PHP code. https://www.php-fig.org/psr/psr-1/ https://www.php-fig.org/psr/psr-1/ I bet massive scale PHP based apps (like you know, Facebook) probably enforce style in their codebase.