Linus Torvalds recently criticized a pull request for introducing a helper function he deemed unnecessary and confusing. In his blunt response, he highlighted the pitfalls of using abstractions that don't clarify intent. He pointed specifically to the `make_u32_from_two_u16()` macro, which is intended to combine two 16-bit numbers into a 32-bit number. Torvalds argued that the macro obscures its purpose, making it difficult for developers to understand the order of the bits without examining the macro's definition. The article expands on this by discussing the cognitive load that comes with ambiguous abstractions. It references a point made by Engineer's Codex, emphasizing that each abstraction costs mental effort to decode. The author suggests that instead of using the original macro, a clearer name like `make_u32_from_msw_lsw()` would better convey which value is the most significant and which is the least significant. This naming change would reduce the cognitive burden on programmers, allowing them to grasp the function's intent without needing to dive into its implementation. Ultimately, the piece stresses that while helper functions can be beneficial, they must be crafted carefully to avoid ambiguity. A well-named function can enhance readability and understanding, while a poorly named one can hinder comprehension and slow down development. The conversation around this topic highlights the ongoing balance developers must strike between abstraction and clarity in coding practices.