Hacker News new | past | comments | ask | show | jobs | submit login

"Not every machine has VSCode, Sublime or Atom installed, but every machine has a terminal."

I love that the article goes from this sentence immediately to:

"These are the main programs I use to make my terminal a complete development environment:"

And proceeds to list 5 different programs, some of which are only available on macOS.

Brilliant.

Edit: One of which are only available*. My point isn't that there isn't a place for GUI and terminal, it's that "not every machine has x and y software" is a fruitless argument.




"Some of which" is actually just one app from the list (iterm2). Iterm2 is just a terminal emulator, so I guess you can sed "s/iterm2/gnome-terminal/g". I must admit that none of these are common default apps.


IIUC, iTerm2 has uniquely good integration with tmux.

If I knew I'd always have Mac as a client, I'd probably switch to using Tmux instead of Gnu Screen just for that reason.


I agree. I feel like that argument is better for a different subset of users. I got into terminal multiplexers when Tmux started getting traction. So I chose that after only using Screen briefly. Since then I've met a few old-schoolers who have used Screen for 20+ years who have asked me to pitch them on Tmux. Maybe I'm doing a poor job, but they already have configs they like and aren't really interested in the new features. Plus, Tmux is missing or not installed by default on older or more obscure distros. The only practical thing I could come up with was better support for vertical splits (the more sanely named and organized config wasn't relevant because they hadn't changed theirs in years). Similarly with NeoVim. I can usually get by with vi on those obscure systems since I'm usually reading a log or tweaking a config instead of editing source code.

On systems I don't administrate using these fancier new tools are a pain. I either have to bug the sysadmin to install my pet set of tools or try find static compiled versions, or try and build them myself in my homedir. I feel like I've wasted a lot of time jumping through hoops for things to mostly work with old versions of things. AppImage (what neovim offers) requires Fuse. s.minos.io which has a handy app to download static builds, is missing new versions and many packages I'm looking for.

The situation for Terminal apps is often worse than GUI apps.

As an aside, the only things I've seen gain traction with old-school Linux users are alternatives to grep since they're so much faster, have better defaults (like honoring gitignore), and are generally compatible with grep's arguments.


Using the terminal at least makes you proficient with the lowest common denominator of tools.

I know I can SSH into any random machine, and edit a config with the copy of vi/vim it has, even if it doesn't have my fancy plugins.

And if I get a new machine, all I have to do is install my tools via Apt/Brew/etc, clone my dotfiles repo, and run an install script.


Still though, the article feels overkill. I use VSCode for example and I'm still comfortable enough with a terminal to vi/vim, install/update, manipulate files, search, etc. Yet I'm not nearly as productive vim as I am with VSCode.

Basically it doesn't have to be an all-or-nothing sort of deal. Just find the combination that makes you productive, and if you find that your productivity is suffering because of one of your tools then address it accordingly.

So far this article reads more like a zealous hyperbolic "It doesn't matter if you think you're productive. You're deceiving yourself and your tools are trash"


> And if I get a new machine, all I have to do is install my tools via Apt/Brew/etc, clone my dotfiles repo, and run an install script.

If I get a new machine I only install

- dotnet core

- Visual Studio Code

Finished.

Both are available on all mainstream platforms that you might want to use, including Linux, Windows and Mac.


>Using the terminal at least makes you proficient with the lowest common denominator of tools.

Why even use a computer then? Aren't rocks and sticks an even lower common denominator?


I don't know, with SSH access to a machine, I would edit the remote file with Emacs on my local machine via Tramp or using SSHFS.


> I know I can SSH into any random machine, and edit a config with the copy of vi/vim it has, even if it doesn't have my fancy plugins.

The android phone I'm currently messing around with had neither vi nor vim...

Yes, knowing the lowest common denominator is great. But doesn't make a great dev environment. OP is describing how to set up a customized one for exactly that reason.


Eh...it's not out of the box, but either busybox or termux will fix that in 30 seconds. The lowest common denominator is extremely portable.


What?

iterm2 is the only OSX program in that list of five.

[edit] Plus, his whole point is that you don't need a GUI to get work done. Not, that you don't need software at all.


Saying that you should learn the terminal because a machine may not have Atom or Sublime is sort of saying that an advantage of the terminal is that you don't have to install additional software, isn't it?


Nah, that sounds just like short for "I sometimes wear the devops hat" - that is, the author probably has to switch computers regularly. Productivity as a devops/sysadmin has different requirements than regular developer productivity. In the former case, you'd prefer standard terminal apps and default settings. In the latter, you'd customize the hell out of your CLI and editing experience.


Yes that's also key for network admins - ironically I found when doing my CCNA that my experience years ago on PDP's cli came in handy on ios (the Cisco os).


Yes. I wonder though, with proliferation of tools for automating server management, how much does this approach still matter?


Serious sysadmins /network admins only config kit via out of band terminal mode - that's what the AUX and Console ports are for on Cisco kit


Eh, that doesn't scale beyond a few devices. There's out-of-band management, yes, but often it's in the form of an isolated management network, which allows automation quite conveniently. Even the serial console is often accessible over a network using terminal servers. You usually also want to be able to download and archive your device configuration automatically using eg. oxidized.

That said, being able to work with standard tools is extremely relevant for debugging problems, still.


There is a difference between pre-installed only vs being allowed to install apps, and CLI vs GUI.

There are many environments that are CLI only. That’s what the author is talking about. You’re talking about environments that don’t allow you to install apps. That’s a completely different discussion.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: