Live data from Hacker News

You Need to Ditch VS Code

jrswab.com

81–90 of 113 posts

Re: You Need to Ditch VS Code

#81
post #71

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…

LLMs make all those commands trivial to learn. Back in the day we had to study whole man pages meant as reference. Like keeping attention for minutes at a time. The horror!

You read the manpages once and then if you're some super elite user you create some aliases for yourself.

Or if you are me, you do `history | grep name-of-command` to find the last time you used it and edit that haha

Re: You Need to Ditch VS Code

#82

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…

mv --interactive

cp --interactive

rm --interactive

Re: You Need to Ditch VS Code

#83
post #66
post #42

Earlier quoted context omitted.

> I personally find them easy to ready anyway, with tools like delta[1] which make things super nice to read. Also if you use a text editor such as neovim you can integrate these things into your editor and get beautiful diffs right there. All I can see here is “if I use two extra tools, I can almost have as good an experience as vscode (or IntelliJ or whatever) gives me out of the box”.

You mean adding a few lines to a config file once and never think about it again? Some people don’t want to have to deal with why they see as a load of bloated ‘features’, preferring instead to just focus on the task at hand, and that’s okay. The article is as misguided as the snarky pushback. Let people work however they’re most comfortable and productive, why does it have to be a purity contest?

Don’t forget installing _and discovering_ those tools.

> The article is as misguided as the snarky pushback. Let people work however they’re most comfortable and productive, why does it have to be a purity contest?

Absolutely agree on it not being a purity contest. The article deserves pushback _because_ it’s arguing for purity

Re: You Need to Ditch VS Code

#85

"You should not let your IDE do the thinking for you" As a solo entrepreneur, if something enables me to execute faster, I'll gladly use it. Articles like this only remind me to never (again) hire expensive, pedantic, over-principled and cynical engineers.

Strange. Articles like this remind me never to hire vibe coding brogrammers who have no idea about basics such as cp, mv, find etc. Usually they leave behind a mess which soon breaks. The cynical and pedantic engineers however, do excellent work, and their software never breaks. It takes longer, you pay a bit more, but it is worth every cent.

Using VS Code !== Vibe coding

And using an IDE that enables you to work faster, doesn't mean you can't learn basic shell commands. Or learn the fundamentals behind the technology you use. Just like pedantic engineers are no guarantee for code that doesn't break.

Re: You Need to Ditch VS Code

#86

Research on calculator use in early math education (notably the Hembree & Dessart meta-analysis of 79 studies) found that students given calculators performed better at math - including on paper-and-pencil tests without calculators. The hypothesis is that calculators handle computation, freeing cognitive bandwidth and time for problem-solving and conceptual understanding. Problem solving and higher level concepts mat…

That you for mentioning that. I have often argued with people in favour of my approach (home ed so I got to choose how to teach my kids from about 9 to 16) of not doing things like memorising times tables and learning arithmetic techniques like long division.

Re: You Need to Ditch VS Code

#87
post #75

I've moved to VS Code after almost 20 years of Emacs. Couldn't been happier. Spent a little time hacking hotkeys to match my Emacs muscle memory and that's mostly it. Now I have a debugger that's actually easy to use, ability to run the test case under the cursor in one click and support for Jupyter Notebooks. However, still missing tab completion.

I follow using Emacs, but for debug and AI.

Using both is not so bad.

Re: You Need to Ditch VS Code

#88

I'm quite surprised to see the need to debug a live server here. I'm of the belief that the need to repro a problem locally and using a debugger lead to better understanding. SSHing into boxen feels like a cowboy behaviour on a modern stack - it shouldn't be necessary with competent observability and unit tests.

Not all environments are equal. Some vendor systems have basically non-existent debugging capabilities that end up dumping you into the wild west when things go wrong.

I have worked with more than one Fintech that provides no test systems/debugging capabilities and have spent time on calls with their developers as we walk through production logs. Not fun.

Re: You Need to Ditch VS Code

#89
post #71

Earlier quoted context omitted.

LLMs make all those commands trivial to learn. Back in the day we had to study whole man pages meant as reference. Like keeping attention for minutes at a time. The horror!

You read the manpages once and then if you're some super elite user you create some aliases for yourself. Or if you are me, you do `history | grep name-of-command` to find the last time you used it and edit that haha

You’re gonna love ctrl-r name-of-command

Re: You Need to Ditch VS Code

#90
post #69

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

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?
Post reply on HN