4 ms·

It was 3800 lines of code before, and it's 3800 lines of code after. Let's spend the remaining 45 minutes discussing why my personal preferences are correct, an

It was 3800 lines of code before, and it's 3800 lines of code after. Let's spend the remaining 45 minutes discussing why my personal preferences are correct, and OOP is garbage.

mpweiher 11y ago
That was my thought as well. In order to justify the crass title, something a little more than a circular argument as evidence might have been called for.
- charlesism 11y ago
  Yes. Plus, it's somewhat arrogant to deride the legibility of someone else's code, in comparison to your own rewrite, considering: (a) It's an order of magnitude more difficult to write original code than to port code from one domain to another. (b) It's an order of magnitude more difficult to understand someone else's code than something you've just finished writing. It would be a different story had he had created the rewrite, and had a third party discuss both versions.
loup-vaillant 11y ago
The procedural version have less files, and less functions/methods. This indicates that many functions in the original code were called only once, so we might ask why they were broken up in the first place. Having that many functions, that are called only once, means you have to make more non-local jumps to read said code. This is not ideal. Moreover, such a break-up obscures the dependency graph in the code. Many nodes (functions) will have only one inbound edge (call). While collapsing the original graph to a canonical form will likely yield the same result on both code bases, the original code still show 3 times as many nodes. This makes it harder to see the real dependencies. Again, not ideal. Finally, there's the possibility that the procedural version made genuine simplifications to the dependency graph. If it really reduced coupling while keeping the LoC count the same, that's a net win. Granted, those measure are not nearly as definitive as the LoC count itself. Still, they do suggest the original code is not as straightforward as it could be. Now to really know, we'd have to read the code.
- lazyjones 11y ago
  > The procedural version have less files, and less functions/methods. This indicates that many functions in the original code were called only once, so we might ask why they were broken up in the first place. Readability, testing? What seems odd is that there are now fewer functions, but the same LOC count, therefore apparently more code/statements. This looks like he had to actually add code to replace the original structure, which seems superfluous.
- WatchDog 11y ago
  Spitting discrete parts of functionality into separate functions, even if called once makes the code more readable even if they only get called once. You don't clutter the would be calling functions scope with variables only needed within the would be in-lined functions body. When you read the code you the function name and return type can describe what is being done rather than trying to grok the body of the function code itself.
  - adnzzzzZ 11y ago
    It might make the code more readable but it makes you jump around more and adds more complexity to the code base. Now you have to consider: under what conditions does this function get called? Does it get called more than once? In which file is it? And so on. Every time you add another node to your code base you're making it more complex, and in this instance it has very questionable gains. It makes as much sense to just say in the first line of this block of functionality what it does to what.
    - WatchDog 11y ago
      I guess im used to working with languages with excellent IDE support. Having more files and jumping around the code to see the detail don't seem to be a problem for me when using a good IDE. While I only got through around half the video I can see hes created 500 line functions with 5 levels of flow control, personally I find that much harder to follow than clicking though to a function or just reading he functions name and API.
viraptor 11y ago
Why not? If someone can provide good examples and create an interesting talk explaining why their personal preferences are correct, why not spend 45 minutes on it? That is what most of the software conferences offer after all. You don't even need to agree with the author at the end to learn something interesting. Or even (OMG) something you didn't think about before and that will improve your super-OOP code.

It was 3800 lines of code before, and it's 3800 lines of code after. Let's spend the remaining 45 minutes discussing why my personal preferences are correct, and OOP is garbage.

mpweiher 11y ago

That was my thought as well. In order to justify the crass title, something a little more than a circular argument as evidence might have been called for.

charlesism 11y ago
Yes. Plus, it's somewhat arrogant to deride the legibility of someone else's code, in comparison to your own rewrite, considering: (a) It's an order of magnitude more difficult to write original code than to port code from one domain to another. (b) It's an order of magnitude more difficult to understand someone else's code than something you've just finished writing. It would be a different story had he had created the rewrite, and had a third party discuss both versions.

loup-vaillant 11y ago

The procedural version have less files, and less functions/methods. This indicates that many functions in the original code were called only once, so we might ask why they were broken up in the first place. Having that many functions, that are called only once, means you have to make more non-local jumps to read said code. This is not ideal. Moreover, such a break-up obscures the dependency graph in the code. Many nodes (functions) will have only one inbound edge (call). While collapsing the original graph to a canonical form will likely yield the same result on both code bases, the original code still show 3 times as many nodes. This makes it harder to see the real dependencies. Again, not ideal. Finally, there's the possibility that the procedural version made genuine simplifications to the dependency graph. If it really reduced coupling while keeping the LoC count the same, that's a net win. Granted, those measure are not nearly as definitive as the LoC count itself. Still, they do suggest the original code is not as straightforward as it could be. Now to really know, we'd have to read the code.

lazyjones 11y ago
> The procedural version have less files, and less functions/methods. This indicates that many functions in the original code were called only once, so we might ask why they were broken up in the first place. Readability, testing? What seems odd is that there are now fewer functions, but the same LOC count, therefore apparently more code/statements. This looks like he had to actually add code to replace the original structure, which seems superfluous.
WatchDog 11y ago
Spitting discrete parts of functionality into separate functions, even if called once makes the code more readable even if they only get called once. You don't clutter the would be calling functions scope with variables only needed within the would be in-lined functions body. When you read the code you the function name and return type can describe what is being done rather than trying to grok the body of the function code itself.
- adnzzzzZ 11y ago
  It might make the code more readable but it makes you jump around more and adds more complexity to the code base. Now you have to consider: under what conditions does this function get called? Does it get called more than once? In which file is it? And so on. Every time you add another node to your code base you're making it more complex, and in this instance it has very questionable gains. It makes as much sense to just say in the first line of this block of functionality what it does to what.
  - WatchDog 11y ago
    I guess im used to working with languages with excellent IDE support. Having more files and jumping around the code to see the detail don't seem to be a problem for me when using a good IDE. While I only got through around half the video I can see hes created 500 line functions with 5 levels of flow control, personally I find that much harder to follow than clicking though to a function or just reading he functions name and API.

viraptor 11y ago

Why not? If someone can provide good examples and create an interesting talk explaining why their personal preferences are correct, why not spend 45 minutes on it? That is what most of the software conferences offer after all. You don't even need to agree with the author at the end to learn something interesting. Or even (OMG) something you didn't think about before and that will improve your super-OOP code.