Live data from Hacker News

Advice to a novice programmer

blog.plover.com

61–70 of 158 posts

Re: Advice to a novice programmer

#61
Regarding #1:

> You lost a lot of time and energy dealing with issues like: Using vim; copying files back and forth with scp; losing the network connection; the college shared machine is slow and yucky.

Sometimes struggling with the tools you don't like and ending up at the ones you do build "character" and some familiarity with struggling with the unfamiliar. Those can be formative even if they're not "efficient" towards finishing an assignment as soon as possible. I think there's a balance to strike here, and as others have noted, some people _like_ vim and SCP, so which setup is "right" is subjective and requires a bit of struggling (albeit ideally time-boxed / within reason) to find it.

That said, I would've _killed_ to have this much help getting started as a novice programmer. I *love* how much effort and care this person puts into helping their kid(s) manage the whirlwind of early CS and university.

Re: Advice to a novice programmer

#62

This is great advice, although personally I will continue using vim over vscode. If vscode is a sharp kitchen knife then vim is a katana sword. Novice programmers should probably not start with vim.

I still don't really understand what Vim users see in it. They always seem to claim that you can edit faster... and sure you can if you're comparing with Notepad++. But modern editors have multiple cursors and tons of useful editing tools that let you be easily as fast with much less pain.

It depends on what you're doing. This article is more about programming than other kinds of computery work. In the industry I work in (openstack devops/gitops, running a large fleet of ubuntu machines), using Vim isn't a flex, it's just taken for granted that you can and will use Vim at least some of the time.

It's weird when I read threads like this and people treat using Vim as some kind of weird flex. It feels like I'm living on a different planet. Vim isn't a flex, it's a natural part of the broader Unix environment. It works seamlessly with Git, SSH, and the GNU ecosystem of bash, coreutils, gawk, gcc (which are all ubiquitous, too.) In such an environment, the more you learn about Vim, the more it pays off.

Why? Vim is ubiquitous, (relatively) lightweight, extensible with a lot of plugins available, and stable/predictable in its behavior. Its ubiquity and history ensures there is a huge body of documentation about it on the web. Unlike some other editors, it doesn't leave hidden "artifacts" all over the place, just one hidden swp file at a time which vanishes as soon as you save and exit the editor. This politeness is attractive because you don't have to deal with stale or interfering hidden statefulness.

Summary: Although you can edit quickly with Vim, and can keep getting faster the more you learn, it's not like I stick with Vim because "editing speed" is some metric that I really care about. And when assessing a candidate in an interview, it's not like I'm assessing them on their words-per-minute and tell them they need to switch to Vim to match our typing speed standards, lol. I use Vim, and I care about Vim, because it is polite and stable and integrates well with the broader Unix/GNU ecosystem I spend a lot of time working and playing in, and once you get muscle-memory for it, it feels really clunky to try using some other tool which doesn't have the same set of features.

Re: Advice to a novice programmer

#63

This is great advice, although personally I will continue using vim over vscode. If vscode is a sharp kitchen knife then vim is a katana sword. Novice programmers should probably not start with vim.

> "...vim is a katana sword."

Vastly overhyped and overrated by Japanophiles, requires a lot of dedication and learning to use properly, and a hassle to use for day-to-day household tasks? Sounds about right, dohohoho.

(I'm kidding, I'm kidding...)

Re: Advice to a novice programmer

#64
post #49

Earlier quoted context omitted.

Jetbrains tooling is amazing. But can you attach to a running Docker container and develop inside it using Jetbrains? Because last I checked I couldn't and was a blocker for my team. With VSCode I can attach to both local and remote environments using Remote Development plugin by Microsoft ( https://marketplace.visualstudio.com/items?itemName=ms-vscod... ). Yes most things are plugins. But they are high quality and m…

What do you mean “develop inside it”? Here’s a link on doing it with python https://www.jetbrains.com/help/pycharm/using-docker-as-a-rem...

Note that this feature is only available in the Professional (that is, paid) version. And since VS Code can do it for free, it has the upper hand in money-tight environments.

Re: Advice to a novice programmer

#65
post #49

Earlier quoted context omitted.

Jetbrains tooling is amazing. But can you attach to a running Docker container and develop inside it using Jetbrains? Because last I checked I couldn't and was a blocker for my team. With VSCode I can attach to both local and remote environments using Remote Development plugin by Microsoft ( https://marketplace.visualstudio.com/items?itemName=ms-vscod... ). Yes most things are plugins. But they are high quality and m…

What do you mean “develop inside it”? Here’s a link on doing it with python https://www.jetbrains.com/help/pycharm/using-docker-as-a-rem...

That's just the python interpreter inside Docker being called from outside Docker. That's basically a configuration to call:

docker exec -i container_name python3 myfile.py

What VSCode does is much more powerful. It's as if you opened VSCode from inside the container. It works because VSCode installs a server inside the container so the world is now your container and you get full isolation, precise tooling and other goodies.

In my case the development Docker file has all dependencies devs need to work on the project. No need to fight with versions of npm, node, Python, Java, Go, nginx, Caddy, yada yada. Everything is configured in the Docker file. Everyone on the team gets a copy of the exact same environment.

We could even attach to a remote container running somewhere in "the cloud" if we wanted to.

Re: Advice to a novice programmer

#66

Earlier quoted context omitted.

I still don't really understand what Vim users see in it. They always seem to claim that you can edit faster... and sure you can if you're comparing with Notepad++. But modern editors have multiple cursors and tons of useful editing tools that let you be easily as fast with much less pain.

can you go a full 8 hour work day without touching the mouse? edit: can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq?

> can you go a full 8 hour work day without touching the mouse?

What does this have to do with anything? If I felt the need to work this way, I absolutely could set up my Mac + any JetBrains IDE to do it, but to me it is an entirely unnecessary requirement.

> can you easily pipe the entire file through grep or awk, or insert the contents of the output of curl or jq?

Yes, and probably from within my IDE (if I cared to), which I probably won't do and don't need to because there exists other tools and plugins.

Re: Advice to a novice programmer

#67
post #50

Earlier quoted context omitted.

It still astounds me that people actually use "lightweight" and "fast" to describe vscode these days. How times change.

Compared to the competition. I don’t use VI or EMacs. I compare code to Visual Studio Pro 2022 or any Jetbrains product. It feels lightweight and snappy when opening and loading a new project, opening individual files, and searching through a repo. I will say though that Jetbrains Idea and Rider are getting much better, but vscode is free whereas those are quite expensive. So if I can get 90% of the functionality for…

I second GP. My point of comparison isn't just Emacs, but also Visual Studio 2015 and 2017, as used for C++. The editor in VS feels snappy, in this general and hard to pinpoint way that lets you easily tell apart a native app from an Electron one. Conversely, despite being reasonably performant (for modern standards), it still feels a little heavy.

I don't know what it is exactly, but I know I'm very sensitive to it. That's the main reason I rarely use VS Code, despite being more feature-packed than VC++ (or, along a few dimensions, even my Emacs) - extra features are nice, but not worth the ongoing discomfort I'd feel with every single key press.

My current hypothesis is that VS Code (and JetBrains IDEs too, so it's not strictly an Electron thing) tends to do too much stuff asynchronously at the same time, making execution times of most actions highly variable and potentially unreliable. The variability usually isn't huge in absolute terms - it's just big enough to be annoying.

Re: Advice to a novice programmer

#68

I really have to disagree with the disparagement of vim/scp at the beginning. It's a bit slower to start if you begin with command-line tools, but the dividends payed out by learning the standard command-line utilities are huge. Learning the command-line utilities means you have the tool-set to build your own tool-set; since it's a lot easier to using CLI tools as building blocks for larger tools. At both of the last…

Just to stay with the analogy: For something to "pay dividends", you need to have some starting capital first. =)

It's much slower to gather the capital when you're starting with zero and you spend weeks just fighting the tools. It's a lot more effective to gather some capital with easier tools (IDE + press F5 to run) and then move in to the low level stuff.

Re: Advice to a novice programmer

#69
post #48

I really have to disagree with the disparagement of vim/scp at the beginning. It's a bit slower to start if you begin with command-line tools, but the dividends payed out by learning the standard command-line utilities are huge. Learning the command-line utilities means you have the tool-set to build your own tool-set; since it's a lot easier to using CLI tools as building blocks for larger tools. At both of the last…

I found VSCode's remote plugins to be a really good option when the code lives on a shared remote machine over a slow connection. vim+scp is an extra step on each change, vim over ssh is just awkward, and sshfs isn't the most reliable piece of software.

> vim over ssh is just awkward

What's wrong with vim over ssh/mosh? I was taught emacs by a grad student back in college and the ability to be fully productive on any server where I can install emacs has been a huge benefit to my career. I can't imagine vim is much different in that scenario.

Re: Advice to a novice programmer

#70
post #65

Earlier quoted context omitted.

What do you mean “develop inside it”? Here’s a link on doing it with python https://www.jetbrains.com/help/pycharm/using-docker-as-a-rem...

That's just the python interpreter inside Docker being called from outside Docker. That's basically a configuration to call: docker exec -i container_name python3 myfile.py What VSCode does is much more powerful. It's as if you opened VSCode from inside the container. It works because VSCode installs a server inside the container so the world is now your container and you get full isolation, precise tooling and other…

I believe that IntelliJ can do this for remote servers. It installs an IntelliJ agent on the server and it’s like remote development, your real IDE becomes a lightweight client of it.
Post reply on HN