• 0 Posts
  • 32 Comments
Joined 2 years ago
cake
Cake day: June 21st, 2023

help-circle

  • For tool configs? I’m not really sure I follow. All my source code for the project goes in src/ or some other subdirectory, and the project root is a bunch of configs, a source directory, maybe some scripts, etc. It’s never really bothered me.

    What has bothered me is __pycache__ directories. Whoever decided to litter those in every source directory all over the place… let’s just say I hope they learned to never do that again. I deal with enough trying to get Python to work at all (with the absolute hell it is to get imports working correctly, the random, but admittedly mostly documented, BS gotchas littered all over the standard library, packages with poor docs, no types, and every function worth calling taking **kwargs, etc). Seeing my code littered with these directories isn’t something I really want to deal with as well.

    A standard for build output might make sense to me. Maybe just throw cache stuff in .cache and build output to .build (with intermediate artifacts in there as well potentially). For configs, I wouldn’t really complain about it all going in .config, but it also doesn’t matter much to me, and sometimes you end up having nested configs anyway in nested project dirs (thinking of eslint configs, gitignores, etc).


  • the highest possible value for a product

    How do you calculate this?

    the amount of people who has the product - the amount of people who want the product

    As demand increases, the value increases, but at some point when demand exceeds supply (which is common), the opposite happens: the magnitude of the value starts to decrease (though that value is now negative).

    For example, two sellers sell a product, and four people want it. Let maximum value be v_m. Value is calculated to be v_m / (2 - 4) = -v_m / 2. If two more people want it suddenly (so 6 now), it becomes v_m / (2 - 6) = -v_m / 4, which has a lower magnitude despite the higher demand and static supply. This is contrary to how supply and demand actually work, where value generally increases as demand increases (if supply remains static).

    Maybe value means something differently to me than it does to you though. Ideally supply would always equal demand (which makes your denominator 0, breaking the equation entirely since that would be undefined), but that would be really difficult to control.








  • The distribution is super important here too. Hashing any value to zero (or h(x) = 0) is valid, but a terrible distribution. The challenge is getting real-world values hashed in a mostly uniform distribution to avoid collisions where possible.

    Still, the contents of the article are useful even outside of hashing. It should just disclaim that the width of the output isn’t the only thing important in a hash function.




  • This would infuriate me to no end. It’s literally the definition of a data race. All data between threads needs to either be accessed through synchronization primitives (mutexes, atomic access, etc) or needs to be immutable. For the most part, this should include fds, though concurrent writes to stderr might be less of an issue (still a good idea to lock/buffer it and stdout though to avoid garbled output).


  • The main value I found from Copilot in vscode back when it first released was its ability to recognize and continue patterns in code (like in assets, or where you might have a bunch of similar but slightly different fields in a type that are all initialized mostly the same).

    I don’t use it anymore though because I found the suggestions to be annoying and distracting most of the time and got tired of hitting escape. It also got in the way of standard intellisense when all I needed was to fill in a method name. It took my focus away from thinking about the code because it would generate plausible looking lines of code and my thinking would get pulled in that direction as a result.

    With “agents” (whatever that term means these days), the article describes my feelings exactly. I spend the same amount of time verifying a solution as I would just creating the solution myself. The difference is I fully understand my own code, but I can’t reach that same understanding of generated code as fast because I didn’t think about writing it or how that code will solve my problem.

    Also, asking an LLM about the generated code is about as reliable as you’d expect on average, and I need it to be 100% reliable (or extremely close) if I’m going to use it to explain anything to me at all.

    Where I found these “agents” to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up. It still takes effort to review that it didn’t start BSing something, but as long as what it generates is small and it’s just editing an existing file, it’s usually not too bad.



  • Ah yes, one of the major questions of software development: to comment, or not to comment? This is almost as big of a question as tabs vs spaces at this point.

    Personally? I don’t really care. Make the code readable to whoever needs to be able to read it. If you’re working on a team, set the standard with your team. No answer is the universally correct one, nor is any answer going to be eternally the correct one.

    Regardless of whether code comments should or shouldn’t exist, I’m of the opinion that doc comments should exist for functions at the very minimum. Describe preconditions, postconditions, the expected parameters (and types if needed), etc. I hate seeing undocumented **kwargs in a function, and I’ll almost always block a PR on my team if I see one where the valid arguments there are not blatantly obvious from context.





  • It’s less of an issue now, but there were stability issues in the early days of DDR5. Memory instability can lead to a number of issues including being unable to boot the PC (failing to post), the PC crashing suddenly during use, applications crashing or behaving strangely, etc. Usually it’s a sign of memory going bad, but for DDR5 since it’s still relatively young it can also be a sign that the memory is just too fast.

    Always check and verify that the RAM manufacturer has validated their RAM against your CPU.