• 0 Posts
  • 48 Comments
Joined 1 year ago
cake
Cake day: July 5th, 2023

help-circle
  • Did you read all the way to the end of the article? I did.

    At the very bottom of the piece, I found that the author had already expressed what I wanted to say quite well:

    In my humble opinion, here’s the key takeaway: just write your own fucking constructors! You see all that nonsense? Almost completely avoidable if you had just written your own fucking constructors. Don’t let the compiler figure it out for you. You’re the one in control here.

    The joke here isn’t C++. The joke is people who expect C++ to be as warm, fuzzy, and forgiving as JavaScript.







  • Let me know if you find one that uses AI to find groupings of my search terms in its catalogues instead of using AI to reduce my search to the nearest common searches made by others, over some arbitrary popularity threshold.

    Theoretical search: “slip banana peel 1980s comedy movie”
    Expected results in 2010: Pages about people slipping on banana peels, mostly in comedy movies, mostly from the 80s.
    Expected results in 2024: More than I ever wanted to know about buying bananas online, the health impacts of eating too many or not enough bananas, and whatever “celebrities” have recently said something about them. Nothing about movies from the 80s.


  • That was my first take as well, coming back to C++ in recent years after a long hiatus. But once I really got into it I realized that those pointer types still exist (conceptually) in C, but they’re undeclared and mostly unmanaged by the compiler. The little bit of automagic management that does happen is hidden from the programmer.

    I feel like most of the complex overhead in modern C++ is actually just explaining in extra detail about what you think is happening. Where a C compiler would make your code work in any way possible, which may or may not be what you intended, a C++ compiler will kick out errors and let you know where you got it wrong. I think it may be a bit like JavaScript vs TypeScript: the issues were always there, we just introduced mechanisms to point them out.

    You’re also mostly free to use those C-style pointers in C++. It’s just generally considered bad practice.



  • As someone who has often been asked for help or advice by other programmers, I know with 100% certainty that I went to university and worked professionally with people who did this, for real.

    “Hey, can you take a look at my code and help me find this bug?”
    (Finding a chunk of code that has a sudden style-shift) “What is this section doing?”
    “Oh that’s doing XYZ.”
    “How does it work?”
    “It calculates XYZ and (does whatever with the result).”
    (Continuing to read and seeing that it actually doesn’t appear to do that) “Yes, but how is it calculating XYZ?”
    “I’m not 100% sure. I found it in the textbook/this ‘teach yourself’ book/on the PQR website.”


  • Most people use the term “Hungarian Notation” to mean only adding an indicator of type to a variable or function name. While this is one of the ways in which it has been used (and actually made sense in certain old environments, although those days are long, long behind us now), it’s not the only way that it can be used.

    We can use the same concept (prepending or appending an indicator from a standard selection) to denote other, more useful categories that the environment won’t keep straight for us, or won’t warn us about in easy-to-understand ways. In my own projects I usually append a single letter to the ends of my variable names to indicate scope, which helps me stay more modular, and also allows me to choose sensible variable names without fear of clashing with something else I’ve forgotten about.


  • I want to say that I wish I could’ve read this 25 years ago, but really, I wasn’t ready to take it to heart back then. In fact, even though I’ve had a couple of minor successes with free games that I deliberately didn’t get too attached to, I still have extreme difficulty just sitting down and making something–anything–rather than falling into a death spiral of over-thinking and grandiose designs. I might have to re-read this a few times to make it sink in.




  • I think that the demographics of gamers have been skewing older and older, and it’s finally reached the point where a critical mass are past the age where they place significant value on the “newness” of a game.

    You can still find 13-year-olds decrying PS3 and 360 games as being “unplayable” due to their perceived technological shortcomings, but every year they represent a smaller and smaller slice of the total market. The surveys I’ve seen lump 18-35 into one group, but I’d be interested to see the results of splitting that into two groups at around 26-27.






  • Re: the Acceptance stage.

    Years ago I worked at a family-run business with a good working environment. The staff were once told a story of how, earlier in the company’s history, a manager made a mistake that caused the company a substantial monetary loss.

    The manager immediately offered their resignation, but the owner said to them, “Why would I let you go now? I’ve just spent all this money so you could learn a valuable lesson!”

    So yeah, generally, most managers’ reaction to accidentally deleting vital data from production is going to be to fire the developer as a knee-jerk “retaliation”, but if you think about it, the best response is to keep that developer; your data isn’t coming back either way, but this developer has just learned to be a lot more careful in the future. Why would you send them to a potential competitor?