Computer guy, occasional gamer, shitty music producer. Denver, CO

https://corytheboyd.com

  • 1 Post
  • 28 Comments
Joined 1 year ago
cake
Cake day: June 16th, 2023

help-circle





  • corytheboyd@kbin.socialtolinuxmemes@lemmy.worldditch discord!
    link
    fedilink
    arrow-up
    7
    arrow-down
    18
    ·
    6 months ago

    I mean, I get it, but when the wrong tool is used so ubiquitously, you have to start asking questions about why people aren’t using the “right” tool. Forums seem to end up being hostile to newcomers, with all this “did you search the forum first you fucking noob?” mentality. Having a living place for real-time questions and discussion just feels better, same way email exchanges feel terrible after using Slack for so long. You can still have incredibly toxic people in real-time chat servers, obviously, but there just seems to be less overall stress to keep the posts in the forum “pristine” or… whatever that was.

    Not being able to search for old content is a huge con to real-time chat. Even if the history is retained forever (in self-hosted instances), real-time messages just aren’t the best bits of data to recall later like forum posts. Clear drawback.

    Still, people are using discord, not to spite forums, but because it works, is free, and is easy.



  • Strings became ubiquitously used for a reason, they map really clearly to the way we think as humans. Most importantly, when you’re debugging, seeing string data is much friendlier than whatever data your symbols map to (usually integers, from enum structures)

    No, obviously it’s not the most efficient thing in the world, but it hardly matters, and you’re not getting anyone to stop because you’re “technically right”.




  • It took me a long time to really grok iterative methods like this, but once it clicks, you will absolutely know and feel like you have unlocked a new super power.

    It starts with completely understanding that you are just passing functions as arguments, abs those functions are being invoked in a loop for each item in the collection. Once that is internalized, you learn the differences between filter, map, reduce, etc. The general differences boil down to: 1. How the iterator function changes the value being iterated over (most don’t) 2. What does the iterator function return (map and filter both return a new list, reduce returns the data structure being reduced into)

    I would skip trying to understand reduce at first, though it’s the method you can implement all other such iterative functions with. The derivations like map and filter are just easier to start with.

    And again, seriously, it took me like 2 years to completely internalize all of this, even after CS classes.



  • It’s a huge faff, you will get a different answer from every person you ask. They’re used interchangeably, and it just doesn’t matter.

    To entertain your prompt. Real world engineers (structural, etc.) aren’t entrusted the title because they “care” about what they build, it’s because they have to be correct, and as such, they follow extremely rigid process and take the time to never be wrong. Obviously I do not have real world structural engineering experience, but I think we can all agree on this from an outside point of view.

    That’s not how software works most of the time, and it’s even heavily discouraged in a lot of the industry. We learn from failure, and the consequences of software failing are nil compared to the consequences of a bridge failing. This is a huge superpower of software, not a weakness, or some sign of deficiency. It is the key reason software evolves so quickly. Software engineers (or developers, alchemists, whatever) are allowed to fail, learn from mistakes, and improve. They can test completely new, never been done ideas, nearly for free, and nearly instantly.

    Again, I don’t really care though what the industry wants to call it, developer or engineer. It doesn’t matter and it’s all made up anyway.



  • I’ve heard it much better described as a “distributed monolith”, which makes complete sense to me. It’s what you get when you “break up” a monolith into “services”, but the spaghetti is still there, it’s just distributed across services now. You have to actually eliminate tight coupling, define the correct boundaries, and vigilantly respect them. All of which should happen from within the monolith first, ideally, where you still have the massive luxury of one codebase to deal with as you make the huge refactors necessary before completely decoupling into services. Even better, do this required prerequisite work and discover that your monolith is actually… fine.