• 1 Post
  • 494 Comments
Joined 2 years ago
cake
Cake day: September 2nd, 2023

help-circle

  • I know this thread is old. But I disagree with you.

    I agree that depending on how you use a debugger, some race conditions might not happen.

    However, I don’t agree that debuggers are useless to fix race conditions.

    I have a great example that happened to me to prove my point:

    As I was using a debugger to fix a normal bug, another quite strange unknown bug happened. That other bug was indeed a race condition. I just never encountered it.

    The issue was basically:

    1. A request to initiate a session arrives
    2. That request takes so long that the endpoint decides to shut down the session
    3. A request to end the session arrives

    And so handling the session start and session end at the same time resulted in a bug. It was more complicated than this (we do use mutexes) but it was along those lines.

    We develop in a lab-like condition with fast networking and computers, so this issue cannot happen on its own. But due to the breakpoint I put in the session initiation function, I was able to observe it. But in a real world scenario it is something that may happen.

    Not only that, I could reproduce the “incredibly rare” race condition 100% of the time. I just needed to place a breakpoint in the correct place and wait for some amount of time.

    Could this be done without a debugger? Most of the time yes, just put a sleep call in there. Would I have found this issue without a debugger? Not at all.

    An even better example:

    Deadlocks.

    How do you fix a deadlock? You run the program under a debugger and make the deadlock happen. You then look at which threads are waiting at a lock call and there’s your answer. It’s as simple as that.

    How do you print-debug a deadlock? Put a log before and after each lock in the program and look at unpaired logs? Sounds like a terrible experience. Some programs have thousands of lock calls. And some do them at tens of times per second. Additionally, the time needed to print those logs changes the behaviour of the program itself and may make the deadlock harder to reproduce.




  • As someone that hates python more each day: you are absolutely wrong on basically every point.

    The only thing you are right on is the non-enforced types (not even warning logs!).

    First, python doesn’t “change all the standards”. Languages are different. If they weren’t different, there would only be one language. There is no language standard.

    for (x in a) is stupid. You want to know what is the “expression” of the for loop? It’s everything after the for and before the :. You don’t need () at all. In fact () would be confusing since you could argue the in is part of the for loop syntax.

    You don’t need to import the types you claim you need to import. list, tuple, dict (idk about set) are available without importing.

    I won’t even explain why you are wrong about data structures and tuples. Just that they are not “array-like”.

    It doesn’t run flawlessly on any OS. Many OS ship with ancient versions of python. So it’s incredibly easy to have your script not run on another computer because you used features that are too new. There are also 3rd party dependencies that are OS-dependant. But you cannot know that until you run it and it fails on some random function call. And after hours of research you figure out that that error is because your OS is not the same as the developer’s.





  • Same thing with git.

    There is no shortage of git beginners that refuse to use a GUI.

    They ask for help for something, I haven’t used git CLI in years, so I tell them “go to this place and click those button”, then they open the vscode terminal and ask “but can I do it from CLI?” Okay then I go to search the command. Meanwhile I tell them to checkout a branch or something as basic as that and watch them struggle for way longer than it took me to find the command I was looking for.

    I get that thousands of elitists have convinced you that using git from a GUI is a sin. But it’s fine, I won’t tell no one. I use a GUI myself.




  • The C example is the wonderful happy path scenario that only manifests in dreams.

    Most projects don’t have a dependency list you can just install in a single apt command. Some of those dependencies might not be even available on your distro. Or there is only a non-compatible version available. Or you have to cast some incantation to make that dependency available.

    Then you have to set some random environment variables. And do a bunch of things that the maintainers see as obvious since they do it every day, so it’s barely documented.

    And once you have it installed, you go to run it but discover that the fantastic CLI arguments you found online that would do what you installed this program to do, are not available in your version since it’s too new and the entire CLI was reworked. And they removed the functionality you need since it was “bad practice and a messy way to do things”.

    All of this assuming the installation process is documented at all and it’s not a “just compile it, duh, you should know how to do it”.


  • Is there anything in the LLMs code preventing it from emitting copyrighted code? Nobody outside LLM companies know, but I’m willing to bet there isn’t.

    Therefore, LLMs DO emit copyrighted code. Due to them being trained on copyrighted code and the statistical nature of LLMs.

    Does the LLM tell its users that the code it outputted has copyright? I’m not aware of any instance of that happening. In fact, LLMs are probably programmed to not put a copyright header at the start of files, even if the code it “learnt” from had them. So in the literal sense, it is stripping the code of copyright notices.

    Does the justice system prosecute LLMs for outputting copyrighted code? No it doesn’t.

    I don’t know what definition you use for “strip X of copyright” but I’d say if you can copy something openly and nobody does anything against it, you are stripping it’s copyright.







  • Generally agree. Except:

    Logs that are a “debug diary” are not useless. Their purpose is to debug. That’s why there’s log levels. If you are not interested in that, filter by log levels above debug.

    Also, the different formats for fields I see as a necessary evil. Generally, more logs (of verbose log levels) = more good. Which means that there should be as frictionless to write as possible. Forcing a specific format just means that there will be less logs being written.

    The json (or any other consistent format) logs seem to be a good idea, but I would keep it to a single debug level (maybe info+error?). So if you want to get wide events, you filter by these log levels to get the full compact picture. But if you are following a debug log chain, it seems a pain to have to search for the “message” field on a potentially order-independent format instead of just reading the log.

    TL;DR

    Log levels have different purposes, and so they should have different requirements.