The Emacs welcome screen links to a tutorial, a guided tour, and manual, all of which are inside Emacs. I would say its help functionality is potentially its greatest strength.
Dude, incredible work. I've only discovered CL in the last couple of months and everything I learn and discover brings me so much joy after being solidly disillusioned with programming after a decade-ish career. The first page of your tutorial cracked me up and a quick glance at CLOG has blown my mind. I can't wait to dig into it all.
Microsoft's interview loop was the easiest I've ever had, it's the only job I've had where I've felt my ethics challenged, and my org's leadership was comically ruthless.
You joined a good org and that's awesome, but I believe you can just as easily join a bad one at Microsoft or a good one at Amazon.
Yes, but they left out explicit murder-for-hire charges in the indictment for that trial. They filed a separate indictment with those charges in a different state which they dropped after the first trial ended.
It's not exactly the same but I see a pattern of using an accusation to influence a trial without intending to prove it.
I don't think that's true. I think the murder-for-hire scheme is a predicate on the conspiracy charge he was ultimately convicted for, in the main trial.
Why would I spend any time stepping through lines I'm not interested in? I set breakpoints on the important parts and let the program run until a breakpoint is hit.
I stop at a breakpoint only after another breakpoint is hit all the time. You set the first breakpoint and run the program. It gets hit and pauses, you set the second breakpoint, then resume.
I'm just not getting how print debugging is the better experience.
This is the only argument for print debugging I can understand. Given the debugger experience I've had at every job in the last 10 years (IDE-driven, set breakpoints in editor, inspect state visually) it's mind-boggling that anyone thinks print statements are superior, but getting that experience can be frustrating depending on your tools and environment.
FWIW my experience debugging Python in VS Code required no setup and I've encountered zero issues.
Why would one step through the whole program? Use the approach you describe for print statements, but for breakpoints instead. Set them, inspect the relevant state when one is hit, then resume execution until the next is hit.
Why would I do this manually using some fiddly UI instead of automating it using the programming language I already have at my fingertips?
Using the programming language itself, I can extract exactly the information I need to see, transform it into exactly the shape that's easiest for me to inspect and combine output from different places in the code to create a compact list of state changes that's easy for my eyes to scan.
What I have found is that my debugging problems are either too simple to require anything more than thinking or too data dependent for a debugger to be the best tool for the job.
Yeah, but what's the cost? RAID5's striping with parity is a cost-saving approach compared to mirroring. If you can afford to mirror all your data that will always be the better option.
