Professional software developer and all-around geek in Seattle.

  • 1 Post
  • 57 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle
  • What a dumb article. Sounds like an old C graybeard who’s never understood the point of proper type safety or readable code. None of the performance gains the author talks about actually matter, whereas the entire point of clean code is to make it easier to read and maintain by other programmers. Let’s also not forget this important quote from Donald Knuth: “premature optimization is the root of all evil”.

    Simply put, unless you’re working in extremely resource-constrained systems, or have some code snippet being run an incredibly large number of times over a humongous amount of data, these kinds of performance optimizations simply don’t matter and you get more benefit from writing the code in a way that reduces bugs and is easier to read. Heck, most of the time compiler optimizations make this entire argument moot anyway.


  • The answer is simple. Games are categorized as AAA when they’re built by large teams with large budgets at large companies. Puzzle games usually don’t require a team of hundreds of people and tens (or hundreds) of millions of dollars to produce. The gameplay and asset scope is tiny in comparison to a typical AAA game. Most games with puzzle elements that do end up getting made by AA and AAA studios (like Portal) have the puzzle aspect merged with some other genre (like FPS, in Portal’s case), and those other genres do require more resources to produce.


  • No, you’re not quite understanding what ActivityPub is. The data under all the fediverse services is not the same infrastructure at all. The communication between those various services just uses the same language (ActivityPub). Those various services can interpret and store (or ignore) ActivityPub messages any way they want. Service instances add another layer to the whole thing as well.

    In order for an “everything app” to be successful (if you buy the argument that it feasibly can be), it would have to be a centralized service. Decentralization, by its very nature, encourages the opposite of that – want to make some niche service because existing services don’t satisfy some fringe need you have, but still want to interact with others on other platforms? You can do that with the fediverse. But that also means your new service isn’t part of an “everything app”… it just can potentially talk to one that might exist.





  • Try chatgpt 4 premium. I have heard it automatically auto correct itself with code.

    I regularly use gpt-4 for coding since it’s the backend behind github copilot, and my company has approved use of copilot (and I have copilot plugins installed for vscode and vs2022). It’s useful for autocompleting boilerplate code, but gets things wrong all the time about anything more complicated.




  • Why would they put META and TIKTOK on there???

    Because they’re alternatives to Twitter?
    Not everybody on the Internet cares about censorship, data leaks, or centralized services. In fact, most people don’t. You just happen to be in a bubble of mostly like-minded people here on the Fediverse. For everyone else out there, now that their digital house is on fire they just want to find a new house that’s as close to their old one as possible.



  • ChatGPT and Bard?

    Doubtful, considering ChatGPT has only been public since late last year, and Bard’s even newer. I also really hope those aren’t a large factor, since most coding examples I’ve seen from ChatGPT only deal with questions of a really rudimentary nature and have given useless or wrong information about anything more nuanced or complicated.



  • The impractical/implausible reason is likely because different groups of people are writing the different fediverse software and have different opinions about how objects are identified in their software. ActivityPub already requires objects to have unique IDs, so this isn’t a protocol issue. But good luck getting every single developer for every single fediverse application to agree on one way to internally represent data in their apps. That’s just never going to happen for a variety of reasons.



  • High interest in something isn’t the same as bubble. Where’s the overvalued assets that are out of touch with reality? The guy quoted in the article even referenced Google losing value after the lackluster launch of Bard, which is kind of the opposite of a bubble. The dotcom bubble wasn’t a bubble because everyone was talking about the Internet… it was a bubble because companies were severely overvalued for putting literally anything on the web without having functional business models. The businesses were the bubble, not the Internet.

    Could AI become a bubble? Possibly. But we’re nowhere near anything like that at this point in time. It’s just got mindshare, not overvalued assets.





  • I don’t think this is a good idea. Keep in mind that different instances have different policies, moderators, and users. This leads to different rule enforcement, culture, and federation status. Even if a magazine/community has the same name and the same discussion topics does not mean it’s the same group of people reading those posts (some might be, due to cross-instance federation, but not all will be). In short, they are different groups and cannot be treated as the same without pissing off people.

    The proper solution is to let each community just evolve until one naturally emerges over time as the go-to community or they all differentiate themselves enough to be considered different (albeit with similar names). Adding a bot to cross-post content just slows that process down and makes the problem persist for longer. If a topic is truly small enough that getting enough people for critical mass is difficult (like your DIY cobbling example), then it shouldn’t be hard to start a discussion in each of the separate communities to suggest assigning one as the “main” one and then just stop using the others. This is something that should be driven by the communities, not the software.