That's interesting. This is kind of what I do to understand and learn new codebases.
I have mostly been working in maintenance and rewrites from scratch, an in most places there's zero documentation, and the business rules are the law. So I often gotta document and copy. Sometimes it's stuff that has been abandoned for years, often in languages/frameworks I never saw before.
This "decompression" step is exactly what I do when I'm lost or in a hurry. I just inline inline inline everything so I can really grasp what's going on.
I have a terrible time understanding deep Java-OOP style abstractions, or Ruby-style meta-programming, even though I've been oscillating between those two worlds for 20 years.
But somehow the terrible abstraction-less inlined code is way easier for me to understand as a newcomer. I don't force it upon others though, and it's the first time I see someone else talking about it.
Actually I'm not being truthful, this John Carmack one crazy idea also follows a similar principle: http://number-none.com/blow/john_carmack_on_inlined_code.htm... . But I still feel like I'm alone with those people that do games like John Carmack, Casey Muratori or Jon Blow.
I think finally we will be able to demonstrate that the deep Java-OOP style abstractions were bullshit at most software shops. Unless you are leveraging that stuff to make your code more testable, maintainable, and performant then just leave it alone.
I think the issue is that middle-aged architects get that "flow" feeling while doing their design work. They should keep that shit in their home woodworking shop and leave it out of the code base!
In many cases, I believe distaste to “abstraction-less” code is an avoidance of discomfort. “I have never programmed like this, this feels uncomfortable, therefore I label it as unclean or bad quality code”.
But then the appropriate time will not be spent designing a clean interface. Instead the abstraction is built upfront and fits the original discovered problem space but not the actual problem space.
Then the abstraction may be coupled tightly, even though it is a class or some form of layer, with the implementation. Then all bets are off.
But of course the programmer who made it goes “ah feels like home”.
I have mostly been working in maintenance and rewrites from scratch, an in most places there's zero documentation, and the business rules are the law. So I often gotta document and copy. Sometimes it's stuff that has been abandoned for years, often in languages/frameworks I never saw before.
This "decompression" step is exactly what I do when I'm lost or in a hurry. I just inline inline inline everything so I can really grasp what's going on.
I have a terrible time understanding deep Java-OOP style abstractions, or Ruby-style meta-programming, even though I've been oscillating between those two worlds for 20 years.
But somehow the terrible abstraction-less inlined code is way easier for me to understand as a newcomer. I don't force it upon others though, and it's the first time I see someone else talking about it.
Actually I'm not being truthful, this John Carmack one crazy idea also follows a similar principle: http://number-none.com/blow/john_carmack_on_inlined_code.htm... . But I still feel like I'm alone with those people that do games like John Carmack, Casey Muratori or Jon Blow.
Anyone else is like this?