7 ms·
This article comes from a person who prefers copy+pasting to reusable macros: "The reason why I have 15 "max" in my code is because it takes less time to copy-
by rootlocus 11y ago
This article comes from a person who prefers copy+pasting to reusable macros:
"The reason why I have 15 "max" in my code is because it takes less time to copy-paste max( 15 times than it is to write a macro and think about where I should put it in my code structure!"
Am I the only one who sees a problem with that?
- kibwen 11y agoSetting aside for the moment that game developers may have a tendency for quick-and-dirty solutions, tomaka is well worth listening to. :) They're the author of glium (https://github.com/tomaka/glium https://github.com/tomaka/glium), which all my OpenGL-using friends perpetually rave about and which showcases how Rust can be used to provide safe abstractions over low-level APIs.
- TillE 11y agoEvery programmer is lazy sometimes. Obviously the author doesn't "prefer" this, it's probably just a resistance to implementing a macro which they think should be present in the standard library. If you only need to do this two or three times in your code, I can see how you wouldn't bother refactoring it, but would include it in a list of annoyances.
- outworlder 11y agoYes and no. If it's a single instance (even if repeated 15 times), then it could be a net win in complexity to just leave the 15 max there – they are more obvious. This is in contrast to writing and maintaining a macro that does a trivial function, just once.
- rootlocus 11y agoThat may be your personal opinion, but 15 'max(' on a single would not pass code review in any decently maintained project, especially when there is a cleaner, reusable alternative. Moreover, complaining that implementing such a macro is too cumbersome because it implies finding a place for it in your code structure certainly doesn't imply professionalism. Just step back a minute and imagine the fresh intern comes to you with this code and explanation. Would it fly? Or are you just finding excuses because he's the author of a well known library?
- kibwen 11y agoYou're a bit too over-focused on so trivial an issue. The game in question is a lone developer's personal side project and isn't even open-sourced yet. Don't jump to the conclusion that a codebase written for fun and developed in isolation has any bearing on that developer's professional capabilities.
- Ace17 11y agoInterestingly, I think it might have. Would you rather hire a "clean code" lone developer, or a "messy" one?
- kibwen 11y agoThat's a loaded question, I deliberately wouldn't judge a candidate based on their undisclosed personal projects. :P tomaka is a well-regarded author of many high-quality libraries, such as https://github.com/tomaka/glium https://github.com/tomaka/glium . This is the output I would use to gauge his applicability for any hypothetical position.
- rootlocus 11y agoThe article is not about a game, is about what could be improved in the core language, from a professional point of view. I may write messy code in my spare time, but I don't. And I certainly don't wait for the standard library to implement trivial things on my behalf complaining there's no alternative.
- kibwen 11y agoIf you read the OP, in literally the second comment tomaka admits that this is the least important item in the list. You characterization of his remarks as "complaining" is uncharitable.
- evincarofautumn 11y agoI don’t even see why a macro would come to mind as a first solution when you can just use a fold.
- SamReidHughes 11y agoThat would be horribly slow.
- evincarofautumn 11y agoWould it? Inlining the fold should produce the same code, with no intermediate vector. Granted, such inlining is not guaranteed, whereas with a macro it would be.
- SamReidHughes 11y agoI don't know about compiler optimization but there's a bit more to it than inlining a fold.
- SamReidHughes 11y agoI just tried it and sometimes it avoided the vector allocation but at least once it allocated and filled the vector, and then immediately deallocated it. (It didn't reread the data back from the vector.)