101–110 of 113 posts
> Try debugging without breakpoints Why would you need to give this up? I use breakpoints with terminal debuggers all the time.
No thank you... One of the primary things shells are supposed to excel at is file system navigation and manipulation, but the experience is horrible. I can never get `cp`, `rsync`, `mv`, `find` right without looking them up, despite trying to learn. It's way too easy to mess up irreversibly and destructively. One example is flattening a directory. You accidentally git-cloned one too deep, into `some/dir/dir/` and wan…
can never get `cp`, `rsync`, `mv`, `find` right without looking them up
I would double down on advising you to go back learning to use the roots before getting IDE or llm assistant...
But for day-to-day dev tasks, having VSCode/code-server/Zed/Neovim/whatever floats your boat, with all the lovely extensions and fonts and syntax highlighting and type hints and whatever you like to use, that's awesome and nothing to shrink back from.
Earlier quoted context omitted.
What is there to get wrong in your flattening dir example? I'd mv the internal dir as some other name to outside say dir2, them rm rf outer and mv the dir2. Unless there is something wrong in this approach. I would agree with the rest, I always have to look up find and xargs syntax.
If you make a typo, it'll go wrong. This is something that file managers fundamentally do not suffer from when trying to do that operation
File managers have nowhere near the flexibility available in the terminal.
I don't suggest to new developers on my team to use Vim, unless they _want_ to learn it. I also don't suggest they learn assembler to write web apps unless they have time to spare.
I also don't suggest they vibe code blindly, and instead spend time understanding the code emitted by any tool. The middle ground of what works best for any task at hand is the right choice.
Earlier quoted context omitted.
If you make a typo, it'll go wrong. This is something that file managers fundamentally do not suffer from when trying to do that operation
You've never mis-dragged something in the GUI or had a flaky mouse button which lets up randomly while you're dragging which left your folder "somewhere" that you now have to find?
I don't trust devs who can't operate outside their IDE. Maybe I'm just old fashioned, but it reminds me of useless Enterprise Java drones who are helpless without Eclipse and can't debug anything.
From the embedded systems end, VSCode really feels like the new Eclipse. For decades embedded CPU companies would look at visual studio and say, "Boy howdee if we only had visual studio for our chips!" But they wouldn't be willing to put in the effort to do so, so they'd start with Eclipse, and the C/C++ plugin, and hack in a JTAG interface, and maybe a few code generators to pin out the hardware and say, look at us…
> Try debugging without breakpoints Why would you need to give this up? I use breakpoints with terminal debuggers all the time.
There is a good argument for never using debuggers except for core development- Once finished your logs/metrics/events should be good enough to understand what is happening in an application. If debugging your application requires breakpoints you wont really be able to debug a live instance, and wont be able to easily signal off what is happening in the future.
Earlier quoted context omitted.
With fish, `for f in *.pdf` Just Works™.
This is also a crutch. Take the time to learn the kludgier tool. It will make you a better developer. /s (I'm a big fan of fish)
/s (no, not really)