I think the one who wrote this title should be blamed. It may not be intentional, but it sounds like Linus is an evil villain who beat RISC-V superhero.
Look at this function that gets submitted to the pull request.
make_u32_from_two_u16()
These “helper” functions never help for the reasons Linus addressed in the article. As a JavaScript developer, which often results in a messy codebase because of management issues, I hate these functions with a passion. It’s usually only the person who wrote it finds it helpful, and only at the week he wrote it. After six months he will just be confused as everyone else.
Garbage, in other word.
Even if it’s not garbage, why submit it alongside the RISC-V change? If it’s a dependency, submit this one first and postpone your RISC-V change.
RISC-V may not be garbage. It’s the industry not getting quality and experienced developers for it.
Its because junior devs get DRY hammered into them by idiot teachers/trainers who dont know much else.
So they try ti DRY absolutely every little function.
Its the one thing I have fought the most dealing with juniors and even seniors.
The other thing is making utility functions into DRY utility functions AND THEN overloading their purpose by adding a bunch of features to it just to justify it being DRY.
The biggest issue I have with Risc-V is the lack of a clear standard. It incredibly fragmented which means that lots and lots of code is needed to try and account for every type of hardware.
Read the article. Can’t imagine anyone who has ever worked with software development not agreeing with Linus here.
I think the one who wrote this title should be blamed. It may not be intentional, but it sounds like Linus is an evil villain who beat RISC-V superhero.
Look at this function that gets submitted to the pull request.
make_u32_from_two_u16()These “helper” functions never help for the reasons Linus addressed in the article. As a JavaScript developer, which often results in a messy codebase because of management issues, I hate these functions with a passion. It’s usually only the person who wrote it finds it helpful, and only at the week he wrote it. After six months he will just be confused as everyone else.
Garbage, in other word.
Even if it’s not garbage, why submit it alongside the RISC-V change? If it’s a dependency, submit this one first and postpone your RISC-V change.
RISC-V may not be garbage. It’s the industry not getting quality and experienced developers for it.
Its because junior devs get DRY hammered into them by idiot teachers/trainers who dont know much else. So they try ti DRY absolutely every little function. Its the one thing I have fought the most dealing with juniors and even seniors. The other thing is making utility functions into DRY utility functions AND THEN overloading their purpose by adding a bunch of features to it just to justify it being DRY.
The biggest issue I have with Risc-V is the lack of a clear standard. It incredibly fragmented which means that lots and lots of code is needed to try and account for every type of hardware.
I don’t code and even I know you don’t do this