It depends on the domain. Any complex long lived mutable state, precise memory management or visual rendering probably benefits from debuggers.

Most people who work on crud services do not see any benefit from it, as there is practically nothing going on. Observing input, outputs and databases is usually enough, and when it's not a well placed log will suffice. Debuggers will also not help you in distributed environments, which are quite common with microservices.

Is there a name for an approach to debugging that requires neither debuggers nor print calls? It works like this:

1. When you get a stack trace from a failure, without knowing anything else find the right level and make sure it has sensible error handling and reporting.

1a. If the bug is reproduced but the program experiences no failure & associated stack trace, change the logic such that if this bug occurs then there is a failure and a stack trace.

1b. If the failure is already appropriately handled but too high up or relevant details are missing, fix that by adding handling at a lower level, etc.

That is the first step, you make the program fail politely to the user and allow through some debug option recover/report enough state to explain what happened (likely with a combination of logging, stack trace, possibly app-specific state).

Often it can also be the last step, because you can now dogfood that very error handling to solve this issue along with any other future issue that may bubble up to that level.

If it is not enough you may have to resort to debugging anyway, but the goal is to make changes that long-term make the use of either debuggers or print statements unnecessary in the first place, ideally even before the actual fix.

In order for this to cover enough space, I assume you‘d have to really pin down assumptions with asserts and so on in a design by contract style.

Debuggers absolutely help in distributed environments, in the exact same way that they help with multithreaded debugging of a single process. It is certainly requires a little bit more setup, but there isn't some essential aspect of a distributed environment that precludes the techniques of a debugger.

The only real issue in debugging a distributed/multithreaded environment is that frequently there is a timeout somewhere that is going to kill one of the threads that you may have wanted to continue stepping through after debugging a different thread.

A different domain where debuggers are less useful: audio/video applications that sit in a tight, hardware driven loop.

In my case (a digital audio workstation), a debugger can be handy for figuring out stuff in the GUI code, but the "backend" code is essentially a single calltree that is executed up to a thousands times a second. The debugger just isn't much use there; debug print statements tend to be more valuable, especially if a problem would require two breakpoints to understand. For audio stuff, the first breakpoint will often break your connection to the hardware because of the time delay.

Being able to print stacktraces from inside the code is also immensely valuable, and when I am debugging, I use this a lot.

Typically trains are powered from above, and subways are powered from the rails. Perhaps this is the distinction, rather than running underground.

Really depends on the region and any pre-existing constraints at the time of electrification. A better distinction is probably rapid transit (metro, subway, the Tube, MTR/MRT) vs commuter rail.

Not in Tokyo. All but the first two of Tokyo’s subway lines run on overhead wires. In fact they had to build most of the subway lines to suburban rail standards because they planned on operating through services in the beginning.

Apparently in the US there are trains that use dual rail and overhead power, one for subway and another for overground portions.

I suppose a subway train with rail only supply that goes overground sometimes is more dangerous because it is easier to accidentally step on a rail and rail is powered?

This is common in London as the suburban rail network there is a mix of third rail and overhead lines.

Typically, trains power themselves.

Also not really true. There are trains all over the world that draw power from over head lines and from 3rd and 4th rail systems.

I design rail systems. That is not true, except maybe in your city.

I'd do separate one on ones. A big one gives off main character vibes.

Part of the idea is to have them meet each other since they are all fascinating.

(and some of it is, I confess, main character energy)

What would be the issue with global lock? I think repo creation is a very rare event when measured in computer time.

I think he is implying that that is neutral, not a loss. It is opportunity cost.

Is the opportunity cost of someone who has never programmed an iOS app before $2500/day as an iOS dev?

Maybe in some analyses, but that’s not where I’d estimate it. If they’re turning down other $300/hr work, sure, but that’s not how I read the account.

It's not about being easily testable, it's about being in an invalid state for an unexpected reason, you can't test that trivially.

You can try to avoid it by architecture or abstractions, but it only works to some extent.

Testing isn't trivial, it can be downright difficult. But if you test for those invalid states, the reasons are expected.

No, this is a pipe dream. The only valid state for a sorted list is sorted. You can not possibly "test for invalid state" here because there's no way you can handle a sorted list that is not sorted in any meaningful way.

Mind you this example is the one of the most trivial data structures in existence. Real software has insanely more complicated valid/invalid state, the size of the state space growing exponentially with the number of components.

If I have a method wrapped around adding items to a list, then I'd call that method with random data. Then, I'd call the method that gets the items from the list and I'd check that the order is consistent. Now, you're testing that the underlying implementation is a sorted list.

I'm sure you can object in many specific cases, but the point is there's no general way to do that. Even your description could be unable to find the famous Java bug with integer overflow in binary search had it only happen on extreme cases. I'm not even talking about race conditions.

And these are still single components, so the exponential growth of state combinations point is left unaddressed. In fact, it directly supersedes your point in this comment, as the exponentiality eats your "random data" idea before you even wrote it.

We're not testing Java, we're testing your code which is a method to add items to a list. If it passes the tests, great. If there is a bug in the JVM, maybe it picks it up or doesn't. That doesn't negate the need for the test.

The way I look at testing is less about the current point in time. It is about changes over time. If someone else comes along and changes the underlying implementation to a list where sort order is not guaranteed (maybe thinking their version is faster or something), then the tests will fail and that's exactly what you want. You're testing the expected behavior over time and right now, the expected behavior is a sorted list.

Regardless, I don't understand what you're trying to argue or prove here. Yes, testing is hard and not easily won, I already said that.

> But if you test for those invalid states, the reasons are expected

I am arguing against your claim that this particular suggestion is feasible for anything but toy projects.

Exactly what I'm talking about:

https://erikras.com/blog/final-form-to-typescript

"Of course, it helped that long ago I had put in all of the legwork to have near 100% test coverage, so I could be certain that the migration did not introduce any bugs."

Suggesting that tests are only for toy projects is some weird kind of ego troll thing you've got going. Look inward.

My coworkers are burning 10k/month on cursor.

how?? I consider myself pretty heavy handed with letting Gemini fill up its 1M token context window for individual tasks, and I don't exceed $20 per day. Do they just let the agent spin in a loop for 4 hours?

The bindings are inefficient doing excessive cloning. But if performance is not a concern then its fine.

Couldn’t you manually edit after generating so you could thereby optimize the code as needed?

That's 18 dollars I was willing to donate without anything in return, so that they maybe perhaps possibly would implement this feature. Which is a lot more money than 100% of FOSS users are willing to contribute.

With paid apps you get exactly the features you pay for, you get customer support, and you get a fair and polite exchange.

It is already a lot for people to swallow to be asked to donate in advance for a feature you need, without any guarantee or even likelihood that it is going to be implemented. But it's a whole different level to put a minimum amount of $20 for such a donation.

I'm just telling my experience as an end-user, and why I avoid FOSS at all costs. Maintainers have only themselves to blame for the situation they've put themselves in.

Wow, I still can't get over your generous nature - $18 to fix an issue for you, you sir, are the veritable milk of human kindness.

Bloody hell, my teenager earns more than that for 1.5 hours of gardening.

I'm not sure if you're trolling, because if you're not, your concept of economic incentives is busted. Completely busted.

But hey, you avoiding FOSS is probably the best outcome for both you and FOSS maintainers, so I do appreciate your decision there.

How much money have you given to FOSS? (Let me guess: 0). But it's good that you are giving them your moral support here online. That's surely worth something.

If your teenager behaves like FOSS developers, then he probably won't get any repeat customers: "Hey man, I might mow your lawn or I might not. Pay me 20 dollars right now and you'll find out, maybe."

I will continue to avoid FOSS. I congratulate the developers and maintainers for all the free labour they provide to make sure the likes of Amazon, Google and Microsoft stay profitable. Their shareholders are surely grateful.

For me, I will continue to purchase high quality software from independent developers.

I have contributed to multiple FOSS projects, so, if we assume my time has value, probably about $20K equivalent at least?

"I care enough to cast $18 of my cold hard earned cash into a black hole for altruistic purposes, but nay shall it be $20, as I am but a humble mortal"

Everybody has their limits of patience. When it comes to charity, you shouldn't annoy donors. It takes a microscopic amount of time for me to close their tab and forget about them. So fuck them.

I get what you are saying, but I think a more charitable interpretation is warranted.

He's saying he asked for a feature, they asked for money, he offered a little money and they said it wasn't enough so he balked.

We can agree on that much, right?

I think, and this is my assumption, that he wasn't expecting the rustdesk devs to come running and immediately roll out his suggestion for his generous $18.

I think he just wanted to put the suggestion onto the pile for consideration, and then when rebuffed for another $2 decided that if he can't even make a suggestion for $18 then it's not worth $20.

Then he went on to complain that they wouldn't even put his concern on the pile for less than $20 and now he's getting (imo unfairly) dragged for it.

This is my interpretation of the events. I might be wrong but I don't think I am.

There is little expectation of return, the way they present it. Contrast that to actually purchasing software, where they are required by law to deliver what you pay for or give your money back.

I'd imagine it's more common that a frontend dev moves to backend dev role.

From my experience a fullstack dev can be a lot more productive than two separate devs when it comes to adhoc work like bugfixes and adding small features.

Also they tend to have very good API design skills, since they understand both sides intimately.