Hacker News Reader

Comment by ARandomerDude | Hacker News Reader

I've worked in 4 different software shops over the last 15 years. My general observation is the developers who rely on heavily automated/magic tooling are significantly outclassed by those who use the terminal + a basic text editor.

Terminal + Vim or Emacs/VSCode (depending on configuration) is not only all you need, it also produces developers who understand the systems they work with.

I know a lot of people will disagree but my advice to more junior guys is always get rid of the toys and learn the tools.

View on HN

> get rid of the toys and learn the tools

A good IDE is not a toy, it is a very powerful tool.

How do you work in a large C++ code base using only a text editor? You will certainly need a couple of plugins, e.g. for linting, definitions/implementation look up, auto complete, etc. Then what is the actual difference to an IDE?

> How do you work in a large C++ code base using only a text editor? You will certainly need a couple of plugins, e.g. for linting, definitions/implementation look up, auto complete, etc. Then what is the actual difference to an IDE?

In the beginning I felt I needed linting, definitions, etc, so I began by stuffing Vim with plugins. Then I discovered that I was much more productive when I didn't use any of that, but actually kept the documentation close by.

Now I just remember most of the definitions or quickly look them up and combine the usage of console applications like grep, find, sed, etc. with Vim. I have about 3 custom made Vim functions that serve as shortcuts for at few of the things I need often.

Personally it's the most productive for me and the tool gets out of the way.

Remembering the core syntax and api's are like magic for productivity, you no longer think in words or variables, you think in data structures and how different endpoints and functions interact, your hands type the code via muscle memory.

Only problem is that the code can sometimes become a bit terse if you do not have an autocomplete, a dumb autocomplete is often enough though.

Does this also work for large code bases? In my experience it doesn't, but maybe my memory is just not very good :-)

It depends how you manage scope. When there are thousands of global variables it will be impossible, but if the language (like Dlang) allows local scoping of imports it's manageable... If you are very strict about what is an actual dependency or just a magic global. The rule is that if the import can be used in other programs/code-bases you can import it. But if it's just a way to get around using global variables you should rethink the architecture. ... Yes IDE's will find the definitions in your spaghetti code-base, but then they become part of a problem loop where the code-base would be unmanageable without the IDE.

Namespaces are also a good solution to use instead of globals or magic globals. But it might become a category theory problem like where in the hierarchical structure you should put something.

The best solution of course is to keep the code base small :)

Hmmm, the whole program still consists of hundreds of functions and I would have to memorize all of them... I don't just work on a single module, I work on the whole code base (open source development).

> The best solution of course is to keep the code base small :)

Hehe, that's the trick. Unfortunately, I came late to the party.

Well. Typically I review the code and say “what kind of twisted sadistic prick wrote this” and then realize that it was me 5 months ago. It’s amazing the level a detail a person can drill into when it’s the locus of focus, and amazing how quickly context is forgotten. Stream of consciousness audio notes would arguably be more useful in such settings than code completion, as the muscle memory is still there, it’s merely the “why” that disappears

> Now I just remember most of the definitions or quickly look them up and combine the usage of console applications like grep, find, sed, etc.

This sounds strictly worse than what IDEs have to offer (I am thinking specifically about C++).

> Now I just remember most of the definitions or quickly look them up

May I ask with which languages you work and how large the code bases are?

Personally, I work with what I'd call medium-sized C or C++ code bases (100k - 200k LOC) with hundreds of functions/methods. There is no way I can remember their signatures. When I start typing a method, my IDE will immediately show all the possible overloads with their parameters. When I hit F2, it immediately jumps to the definition. I seriously can't imagine how abandoning these features could make me more productive.

I'm always stumped when I hear people saying they are more productive in a text editor, even if they had already tried IDEs. I honestly like to understand how this is possible.

Kiel has some tools I’ve not found an integrated easy way of replicating in emacs etc. Mind you, a simple make file suffices for most smaller projects

Not OP, but I guess his point is that all those things are either accessible from the command line (linting) or available as plugins from vim.

As an additional point: I've been working on a "polyglot" project for some years now, most of it is in Python (data-analysis) and C# (Unity), but there is also C/C++ (real-time components) and even some Haskell (some small "scripts") in there.

I do all my programming in vim with basically just syntax highlighting, relying on the web for "definition look up" and typing fast instead of "auto complete".

Code lookup (i.e. "where did that function go") is handled by RipGrep, continuous builds are handled from the command-line (with fsnotify), etc.

=> Definitely just "my 2 cents", but I've been using Vim for so long that every IDE text editing feels very sluggish in comparison.

I especially love (!) the Java projects that run only if you have eclipse with specific plugins. "I don't know how to make it work with IntelliJ" is one comments I often hear from some Java devs. I personally would be too embarrassed to say something like that. I guess the same applies to some VS projects, msbuild was dragon territory when we had to deal with it (so, before dotnet cli came).

I strongly disagree. It’s true that people who do not understand how to use something basic to accomplish their goals are far behind in terms of fundamentals compared to those who do, but it’s provably false that primitive tooling is superior to modern IDEs.

Even just adding NERDTree or ctags to vim dramatically improves productivity. Repeat ad nauseam and you have the modern IDE.

The advice “get rid of the toys and learn the tools” doesn’t do much other than reveal your (subjective) bias for “toys” vs “tools”.

For me, it comes down to one's affinity with the command line. I've known developers who use an IDE but who are still very fluent in the command line, and in fact could probably do just fine if you took the IDE away and made them work in Vim for a while instead.

The problem is when a developer can't make that jump when necessary. A big part of our ability to build systems for computers relies on our ability to traverse those computers at a low level, and that means command line instructions. It means being able to work with the filesystem, and streams of input/output. I don't use Vim because I think it's a superior text editor, I use it because of the fluidity it offers me in terms of getting streams of text from the console in and out of an editor. I can just pipe things to it, or execute arbitrary commands and capture the output, and so on.

Now, granted, seasoned developers can often get that same degree of command-line fluidity while still working in an IDE. But I think that requires them knowing the importance of that fluidity in the first place, which is something that you aren't necessarily going to learn as long as the IDE is holding your hand and doing a lot of it for you.

Definitely prefacing this with the fact I use “just” a text editor and terminal so obviously I am biased.

I couldn’t agree with you more. I feel like at some point in a career, a developer should try to shove off from an IDE if that is their daily driver.

I also feel this way about high level languages.

Speaking personally, I have ALWAYS benefited by doing those uncomfortable deep dives.

Agree 100%. Moving off an IDE fixed my impostor syndrome and instantly made all my code more readable and maintainable. Even my manager has commented on how much profit our team is generating ever since we moved to text editors.

I used to do my share of vim in the past, but I really don't have time for this shit anymore. I just want something that works out of the box across languages, without having to tinker around.

Vim is a great text editor, and that is exactly what I want it to do. The IdeaVim plugin gets the job done for me.

I have programmed Java/Kotlin/TypeScript for 5+ years in terminal/vim. Then for 3 years in Eclipse. Then for 8 years in Intellij IDEA.

I would never go back to VIM for coding.

You were coding in Kotlin and TypeScript 16+ years ago?

No, Kotlin since 2015, TypeScript since 2017.

Managing a large project with basic tools is a nightmare, it also sucks for learning an API. I've tried to use VS Code for C++ and C# stuff, but it's such a poor tool compared to Visual Studio proper.

I don't feel I'm learning anything useful by wrestling with the fiddly JSON build configurations in VS Code.

This. Let me state my assumption and philosophy first. I believe strongly in learning and investing in the fundamentals — things that stay more or less the same for a long time.

There will be another new and _modern_ IDE tomorrow. Why invest and learn something that keeps changing? It’s like spending most of your time learning React or Angular, while you could have spent the same time learning JavaScript itself. I am not saying tools are not useful. IDEs, high level frameworks absolutely boost productivity. If your goal is to get something done fast, sure use these tools. But if you want to make long term investments, you should learn the fundamentals and later potentially use these frameworks (when you understand how they work) to further boost your productivity.

But people often get used to the tools they use, so people with a learning mindset, who start with the fundamental tools tend to stick with them. That’s why I think a correlation exists between engineers who have a good deep understanding of how a system works and engineers who use basic tools.

Could this not simply be explained by the fact that devs who use older tools are more experienced?

Maybe that needs to be controlled for, too.

I do think there is room for nuance.

I learned to code like you suggest. I started with C, in vi, I learned it from the words of Kernighan and Ritchie and I had no forums or syntax highlighting or anything to hold my hands, and when stuff didn't work, I got compiler error messages so obtuse they might as well have been in Linear B, I walked uphill both ways and it was -40 and blizzard even in the summer. I do absolutely concede the type of language-understanding and skill set this promotes does make you a better developer.

However.

I do not think that stubbornly refusing to use an IDE makes you a better developer. A good IDE is powerful, and can be a real force multiplier that makes you able to work with much larger systems and significantly cuts down on the amount of time you spend doing menial repetitive typing.

You can absolutely subsist on the simplest of tools, but you can absolutely do more with the more powerful ones.

I would tend to agree for most languages I have touched (Python, C, ...) but I have mostly worked in medium codebases.

Do people think it is still the case for large code bases and Java? I find the ability to quickly jump to definition in the IDE a huge help when on boarding into a new codebase.

I work "unofficially" on Java code because the Swift code I'm officially responsible for executes Java code (via HTTP request). I'm "not licensed" to use real Java IDEs.

Visual Studio Code's Java support is not great and I do not have jump to definition. Find " name_of_function(" in files is good enough and catches a few useful cases outside Java's understanding, particularly when you have naming consistency throughout a codebase.

Code's not as good as Emacs, but it's reliability installed on nearly every developer's machine regardless of discipline or at least the subset who are willing to ask for help when they encounter problems.

Jump to definition works fine in vscode. I wonder what’s wrong with your install.

Given that VSCode Java support is being done by Microsoft and Red-Hat together, I wonder how come it isn't working for you.

My experience is that those who still use Vi/Emacs to code are close minded and unwilling to change.

It’s certainly possible to code without support, but if you value your productivity, why spend five minutes doing a manual renaming when your ide can do it in a few seconds? Why wouldn’t I want my ide to indent correctly, according to eslint rules in the given project?

Sure for none coding task emacs is great, and git is more powerful on the command line. I therefore use the most powerful tool I can.

Edit: this comment became overly critical, it is quite possible that it is a coincidence, my N is quite low.

>why spend five minutes doing a manual renaming when your ide can do it in a few seconds

That's a LSP feature, you do not need an IDE.

At the risk of being pedantic; it's just a feature, it does not have anything to do with LSP. Plenty of non-LSP IDE's have these features as well (XCode, Visual Studio Classic, etc).

"that those who still use Vi/Emacs to code are close minded and unwilling to change."

Vi is not just an text editor in the terminal. It's a different way to interact with text. To say that Vi users are close minded is like saying people who use the terminal are closed minded.

GUIs and the mouse have significantly improved the way we interact with computers. However, many things are still better in the terminal with a keyboard.

In that same vein, IDEs have improved the way we write code but it has not improved on the way we interact with text enough. For those of us who love Vi as an expressive language to interact with text, we choose to forgo the benefits that IDEs give us when writing code.

Personally, when I write code, I love the experience of tmux with neovim. It's something I try to replicate in the gui every couple of years in MacOS but it always so bad.

On the point of manual renaming, Vim is perfectly capable of project based search and replace.

But, well, what is so different in the way to interact with text exactly?

You start in a file where you aren't even editing yet. From there, to start almost every type of navigation, highlight, or edit action will often be a few character combinations. Go to the end of a file and adding text to the end of the line would be "GA", for example. Most actions don't require adjustment of your hand placement (and its even better if you remap capslock to escape) or use of a mouse. Whatever action you take can be repeated with a simple period (big time saver if you need to repeat an action mutliple times). More powerful commands like find and replace are available with the command mode. It works perfectly well over a remote session, also

Once you learn the keys that correspond to your desired actions, everything else feels wasteful (Especially as I'm writing this on my phone). I turn on vim keys for anything that has it. It takes a long time to build up your vim vocab (I recommend you learn the simple stuff and incrementally look up better ways to approach things as you go). A great way to get started is vimtutor, which is built in when you install vim; just run vimtutor from shell and start reading. There's a lot more depth to what is possible, buffers, plugins, etc. but that's what stands out to me.

Vim has a concept of an object and actions/motions that can be applied to the object. You can think of it as nouns and verbs. Vim objects can be letter, words, sentences or paragraphs. Say you have the following sentence:

"How much wood would a woodchuck chuck?"

If you cursor is on the letter "H", you can type the "dw" to delete the word "How".

You can use "dt" to delete up to a letter. If your cursor is at the letter "H", "dtw" deletes up the letter "w" which will delete "How much ".

This barely scratches the surface. There is a steep learning curve involved but it's totally worth it if you need to edit text on a regular basis.

VIM people are very bad at explaining this. Basically, VIM allows you to compose commands together, so that learning one command means that you can compose it with another to do things very quickly.

The best example is this, imo. you have a function call that is: `combineFirstAndLastName("John", "Smith")`

If your cursor is in the `"John"` part, and you want to change that, you can just input `ci"`, (c)hange (i)nside ("), to instantly start typing with John being removed. Lets say you want to change all the text inside the parenthesis, you just type ci), (c)hange (i)nside `)`.

There's commands like this all over, and you can compose all of them. For example, `ct"`, (c)hange un(t)ill ("), which will erase any text until the next available `"` on the line.

Or, (d)elete un(t)ill `char`. It's a whole language when you're editing with VIM, and while it might sound like that's very hard to learn, it's not. Because you can slowly add these verbs and sentences into your habits until it's completely natural

>It's a different way to interact with text

>On the point of manual renaming, Vim is perfectly capable of project based search and replace.

I think that is my point, stated better than I could, code is not just text.

I have no issue whatever accepting that Emacs/Vim is much much better at dealing with text - I use Emacs for text in preference to just about everything else.

My preference is IntelliJ, but essentially all the IDEs treat the code as a representation of the abstract syntax tree it is. Put your cursor over an identifier and IntelliJ will highlight all the other instances of that identifier. It will not highlight the same word when used in a comment, because it is not the same.

When you treat code like text, you are limited to search and replace. When you treat it as an AST, your editor can rename your private backing field without renaming your property, because it knows they are two different things. In Java it can push methods up and create a new parent class, all while updating all the code that uses it and give you the confidence that it does so without screwing up your code base.

Using toys since Turbo Basic 1.0 and Turbo Pascal 3.0.

Somehow my 35 years of coding experience have shown me that I rather play with those toys than be frozen in past I grew up on (ZX, MS-DOS, UNIX and CP/M).

I've seen this be sorta true over the last 25 years at numerous places but only in limited environments where 99% of the code written was scripting based web languages. I most often work in Python now professionally (mostly security), at home it's C++ and Swift (gamedev). In Python/Js web work that holds some truth, in Security a little more, but in data science/engineering A LOT less where Jupyter and PyCharm are huge. My outside work is 100% in IDE's, XCode - CLion - PyCharm - Intellij, and in game dev or mobile native app dev? The vast majority of great developers are on IDE's. So to me drawing that conclusion is very risky in general and often bad advice to give to Jr's IMO unless they have a very narrow focus on the Web.

I might have agreed with you, until I saw an experienced Java/Kotkin guy work with IJ and a large code base. He was narrating his thought process and coding at the speed of though / speech. It was a thing of beauty that no text editor can help you achieve.

Sometimes I worry that powerful IDEs just make people write more complicated code.

If all you have is a basic text editor, you are limited by what can fit inside your head. If your IDE makes navigation too easy, you end up writing callbacks that call callbacks that call callbacks until you end up in abstraction hell and have no idea what your code is doing anymore.

Then again, better tooling makes refactoring/simplifying code easier so it may just as well lead to easier to understand code...

I agree 100%, I have the same observations.

Does it coincide that terminal masters are also order of magnitude older - and more experienced?

To me it’s a red flag when developer uses notepad++ instead of jetbrains.

Reply on news.ycombinator.com