Hacker News Reader

Comment by gfxgirl | Hacker News Reader

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot.

I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster than opening a shell and trying to grep all the project files for word phrases which, not being language aware, can't tell if one 'foo' is relevant or irrelevant from another 'foo'. They'll also let me refactor various things from renaming a method/class/variable/function and correctly fixing all the related files to doing things like changing class members to getter/setters and other things.

The difference is like using a hammer vs using a nail gun. There are times where they hammer is useful but given the job of constructing a building a nail gun will get the job done much faster.

View on HN

Cool.

Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE.

Starting out, or only ever leaning an IDE is also hiding a lot of things from you.

For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no IDE. An IDE is a great tool, but it shouldn't be a crutch.

And vim without extensions - I'm pretty sure that's a rare thing among programmers.

>> Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE.

Yep. Another thing I hate is IDEs that build their own project files that tie you to them. A good IDE works with standard tooling, not as a replacement.

I could not agree with this more. I've worked on projects with some unholy combination of (gnu) Makefiles and VS Solutions. I've never "got" Visual Studio and have always found it very jarring -- but I mostly don't use windows much, and that always feels like it has a way of thinking that is...very orthogonal to mine. KDevelop has honestly been the best "not in your face" IDE I've personally found. I mostly do not do any MacOS programming, but when I have occasionally played, I've realised that xcode is brilliant but it seems like it utterly reinvents itself every major revision number. Eclipse, something I rarely-if-never used has sunk from a popular zeitgeist without a trace. Many of my colleagues (in a medical imaging setting) use jupyter, RStudio or Matlab, occasionally venturing into julia.

The winds shift, and the ship of progress sails a direction that is difficult to chart, but vim....vim never changes, and for that I am very glad.

I'm not really an IDE person but I find native Netbeans projects easier to understand than Maven ones.

Cant we make this argument for any level of abstraction?

A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.

Emotionally, I actually agree with this. I'd love for at least a basic understanding of computers down to boolean logic and the very basics of semiconductors up to the OS level and beyond to be "widely known" by programmers and "computer literate".

At the same time, I know that's extremely unreasonable to expect. I guess for the shell and editor, you can argue you ought to understand it stripped of abstractions, since it's actually the level you're working at, while most people don't work at the logic gate level.

You may like "The Secret Life of Programs" by Jonathan Steinhart.

It starts at boolean logic and works up to a web browser and then some other stuff.

Edit: It's a high level covering of each topic of course, it does have to fit in a book. It's ~444 pages.

Another book recommendation: "Elements of Computing Systems" by Noam Nisan and Shimon Schocken.

It doesn't go all the way down to the physics of semiconductors, but it goes down to logic gates and all the way up to tetris (there's a related course/website called nand to tetris: https://www.nand2tetris.org/)

If you want to go further down, check out Jeri Ellsworth's old videos where she built a transistor at home: https://www.youtube.com/watch?v=w_znRopGtbE

> At the same time, I know that's extremely unreasonable to expect.

However, that's exactly the path every Electrical & Electronics Engineer classically took.

Yea, this was basically my computer engineering curriculum. Start at solid state physics, build a transistor, boolean logic, digital circuit design, cpu design, operating systems and device drivers, and then software engineering.

Most people in my class ended up at the top of the stack (operating systems and software engineering) since the jobs are more numerous and the pay is better.

As an EE and compsci major, I loved knowing how to form a transistor with n and p types, how to form NAND gates, how to deal with clocks and timing (ok, that’s a lie), how to make vhdl turn into fab rules, how cpu and system design influence compilers, how to write a compiler, various programming languages, np completeness (ok, eh), program design, architecture, distributed systems, machine learning (getting there).

The usefulness of knowing the whole stack has diminishing returns though.

It can be helpful in a large company where I can make connections that others can’t, but in a small company it’s less relevant unless I were solely focused on one specific connection (say, how machine learning using math as designed in an ALU inside a CPU or GPU is ludicrous—go analog and get four orders of magnitude speed up, all that time waiting for carry bit propagation, yuck!)

Your time is probably better spent learning to be a good generalist or specialist in your field, rather than knowing inside so many layers of abstraction.

>Emotionally, I actually agree with this. I'd love for at least a basic understanding of computers down to boolean logic and the very basics of semiconductors up to the OS level and beyond to be "widely known" by programmers and "computer literate".

cf. https://www.pbs.org/show/crash-course-computer-science/

No, it won't give you the level of understanding that an actual comp sci/engineering degree will (after all, it's just a couple dozen ~10 minute videos), but it does touch on all the major concepts and through the series builds on concepts presented earlier.

Absolutely true! Ordered an FPGA dev kit last week for this reason.

Perfect world, you know everything.

In reality, you can't and don't need to. Knowing some shell stuff will be useful for most if not all programmers.

You know nothing..the vhdl to lut transformation (and the content of the bitfile) are totally locked trade secrets.

I got the QuickLogic dev kit - it uses the fully open source Symbiflow toolchain.

I think my chances of ever understanding what Symbiflow does are quite small, but that is a shortcoming on my side :D

And even if I do, I have to learn semiconductor fabrication next!

> Cant we make this argument for any level of abstraction?

We could also make the opposite argument for any level of abstraction: can you really say that someone who buys apps for their iPhone and runs them is less of a programmer than someone who actually programs? If programming is just getting a job done, and being a good programmer is just picking the right tool to get the job done...

The real question is pragmatic, not theoretical. Does your dependence on a tool sometimes make easy things impossible or encourage misunderstandings about lower level processes that lead to bugs or inefficiencies? Is it simply too big or expensive to run in all of the places you might want to program? Does the tool make up for that lack of flexibility with increased productivity? Those are real questions that you can ask about any specific tool (including the shell.) It doesn't mean anything to ask them about tools in general, and the idea that sacrifices and benefits must all come out even in the end is just the law of averages.

Still, a lot of people start out programming with complex compilers and end up being unable to hand-write their assembly code in pure HEX without the "help" of their compiler.

Starting out, or only ever leaning a compiler is also hiding a lot of things from you.

Now, I am familiar with assembly, I live and breathe it honestly, but I don't gatekeep and say "you're not a real programmer unless you've written your own assembler macros". Some people are happy in their IDEs and see no reason to move to the lower-level of abstraction in their tooling. I don't see why we should fault or shame them for that.

Personally, I see shell as a poorly-designed, very error-prone language and I think we should move past it, onto far better tools.

Where did I fault anyone, where am I gatekeeping?

I'm talking about the befits of knowing more stuff.

I'm not arguing against IDEs, I'm only arguing about the benefit of also knowing other stuff.

Better tools: I'm very interested in, what I would in lieu of a better term describe as, Bret Victor's ideas and the example of Swift playground. At the same time, I'm very sceptic against everything that isn't a simple, human readable Textfile underneath. One thing I keep thinking about is making diagrams executable, but I haven't seen a graphical programming language that convinced me. Still, I think this could happen some day, if someone finds the right design.

By framing the IDE as a crutch, that's very much in the gatekeeping category.

I didn't mean to frame the IDE as a crutch, I'm merely saying that you should try to not let it become a crutch aka. overly rely on it.

I recently worked with a colleague who couldn't run the python program he wrote without the IDE. The IDE was not installed on the PC we were testing the program on.

He is a better programmer than me.

And I'm not saying "people who are using IDEs don't know anything".

I'm literally only talking about the benefits of also knowing some basic shell and CLI stuff.

For a lot of people, the IDE does end up being a crutch. I was one of those people, and I can honestly say that over reliance on IDEs really held me back. I became a much stronger programmer when I ditched the IDEs for most tasks. I'll still use IDEs for a few select things, but overall they tend to hide a lot from you and you end up learning the IDE instead of the concepts of whatever language or framework you're working in.

Is "gatekeeping" now just another word for making people feel bad? Like "pretentious" or "elitist" has become? Nobody is saying that people with crutches shouldn't be allowed to walk.

edit: It's so strange to not only demand the right to not know how to do something without a complicated tool (a right which is inalienable and not threatened), but to also demand that people who do know how to do that thing not think that it is better to know how to do that thing. I get that when one has invested their time into a tool they want to defend its usage, but people who aren't dependent on a particular vendor's tool have also invested time, and should be able to think it's better to not be dependent on a particular vendor without it being considered violence or bullying (in the modern twitter sense.)

I mean shouldn't you feel bad if you're trying to discourage active engagement in a topic if one doesn't do it in a specific "correct" way?

Personally I've found a diverse set of viewpoints to be incredibly valuable on the teams I've been a part of. I have my own biases on testing, stability, performance and seeing how others approach it has broadened my understanding of how to build software.

To put it another way, the parent could have said "IDEs are awesome and I've found when you combine that with an understanding of the CLI you have an awesome set of tools at your disposal that are greater than the sum of their parts" instead of making it an exclusive trade off or implying that IDEs are limiting.

> instead of making it an exclusive trade off or implying that IDEs are limiting.

But that would be a completely different argument. Their whole point is that there /is/ an exclusive trade-off, which is different from what they're trying to say.

If you want my opinion, they both piss me off, just in different ways. The IDE requires me to use my mouse, even with the best Vim impersonation plugins. I hate that, but I put up with it because the autocomplete, syntax completion and indexing just works so much better than the Vim equivalents which fall apart under heavily load. And conversely, trying to edit remotely complex projects is a nightmare with Vim, no matter which distributions I use.

Which maybe is a different tone of saying exactly what you are saying.

I literally said that "IDEs are great tools" and my whole argument was that people can broaden their understanding by also learning some shell in addition to their IDE.

So not sure what your point is.

I'm sure that was your true intent, but the way you framed it made it seem like it was in exclusion(the dismissive "Cool." at the top didn't help).

At the risk of sounding patronizing as much as we'd like to everything to be binary pass/fail and survive on the technical merits or semantic details, how you frame things and driving communication in an inclusive way is important of you want to convince people that something is worthwhile.

I agree, but I can only control how other people understand my words to some degree, especially in a fast paced, low effort forum conversation. The prejudice of the reader will drive their interpretation more than my actual intent.

You can read my comments as gatekeeping or as the exact opposite - an invitation to come through the gate and see what you can learn here and take what is useful to you.

> Some people are happy in their IDEs and see no reason to move to the lower-level of abstraction in their tooling.

True but you're also at the mercy of whatever company is responsible for developing those IDEs. I'm not advocating everyone do development in shell but I feel like you should know what's going under the hood when things go wrong.

> True but you're also at the mercy of whatever company is responsible for developing those IDEs.

With all the IDE companies being so ruthless, I wonder where are all those screwed-over IDE users running to.

I mean, we know the answer to this as it started the argument, right?... vim, emacs, and a handful of programmer-oriented GUI text editors such as Sublime Text (or whatever; I don't use them so I might be mixing up "what's cool" or be so out of date as to be laughable).

its always beneficial to learn technology at a lower level. if you are running Windows, its good to learn Powershell. if you have a refrigerator, it is good to know how to change your water filter, clean your fan etc. the purpose of the article is simply stating that familiarizing yourself with posix shells is beneficial to a modern day programmer and I don't think anyone can argue with that.

> Still, a lot of people start out programming with complex compilers and end up being unable to hand-write their assembly code in pure HEX without the "help" of their compiler.

I will reply with a car analogy. You can be a professional driver even if you don't know how to write the chemical formula for the combustion in your motor. You can not be a good professional driver if you don't know how to change a flat tyre or check your oil. No matter how good your driving is, if you cannot change the oil you are an incompetent driver. Maybe in the future, cars will not need oil. So good, but today they do and you need to deal with it.

Likewise, today's computer systems rely on the shell. If you are shell-illiterate, you are an incompetent programmer, no matter how good your programs are.

I didn’t really started out with IDE I become overwhelmed by using an IDE its just my personal preference but I love using text editor they are very simple and minimal

My understanding, as an exclusively nix developer, is that if you’re a Windows dev, all you really have are IDEs. Yes, I know about Cygwin and WSL and the rest, but if you’re a run of the mill Windows developer then your life is centered around Visual Studio and NetBeans and PyCharm and maybe Powershell and maybe maybe cmd.exe if you’re a greybeard.

That vim and bash and all of these terminal-driven ways of developing are the unique privilege (and I do say that unironically) of working with *nix systems.

That’s not to say Windows devs don’t use vim, but in my (limited) experience, it’s about as common as using a gas-powered generator to charge your Tesla.

Agreed. IDEs were how I was taught in class, but discovering shell tooling on my own removed the magic and made programming a transparent process.

I entirely agree with you there is a time for the shell and a time for an IDE and knowing when and knowing both is a huge win.

My comment is more addressing the article where in the author mentions vim with no extensions and grepping. IMO that's often the wrong tool for the job (writing code). It can be a useful tool but there are often better tools for that job. Knowing when to use one vs the other and therefore knowing both is very useful.

I do like my IDE but my one complaint with leaning on it a lot is that it lets you write code that is harder to understand if you don't have that IDE readily available.

For example, if you name a member "flag" and you have several types with the same member, your IDE can tell you where this flag is used, so it's not a big deal if you wanted to refactor or are trying to track down a bug. But god help you if you're looking at your code in a diff viewer or in your browser in an online repo.

A better example might be perpetuating typos (and other less obviously wrong bad names), the number of times I've seen some variant of "setIntercetpor" or "closeDataSteam" or... anything that gets actually typed as "most of the first word plus completion."

Your example sounded like results produced with editors that do not understand the underlying language. A proper IDE would not prompt you with closeDataSteam if it's not a member function of the object to which you want to close the data stream.

Right, the typo was done once and from then on the IDE offered it up for auto completion.

Intellij would mark those with squiggly underlines and even jump there in an otherwise error free file when you press f2.

I think it also comes into the language design. If you expect programmers to use an IDE, then language features and best practices can require large amounts of boilerplate, on the expectation that the IDE will be generating that boilerplate. For languages expecting no IDE to be used, the language itself needs to avoid that boilerplate.

I'm not really sure of your point. I can't imagine naming something "flag" but I can imagine "enabled" or "visible"

In my experience it's not common to name members/properties taking other classes into account so I might have a Window class with "visible" and Shape class also with "visible" and Player class with "visible". I don't think I've ever seen a project where they made those "someWindow.windowVisible", "someShape.shapeVisible", "sompePlayer.playerVisible" just for the sake of searching regardless of if they person is using an IDE that could tell the difference or just notepad/nano.

All of my experience is they would all be just "someWindow.visible", "someShape.visible", "somePlayer.visible". In other words, that choice has nothing to do with IDE or no IDE.

Is there some other example you were thinking of?

1) I'm not going to teach Jenkins to use IntelliJ. I want my build step (whether gradlew or make) to be runnable in the same way as it runs in scripts. I get to set (and read!) env vars when they're right there in front of me, not hidden away behind dialog boxes.

> 1000x faster than opening a shell

Don't close the shell.

> trying to grep all the project files for word phrases which, not being language aware, can't tell if one 'foo' is relevant or irrelevant from another 'foo'.

IntelliJ is the gold standard according to my Java buddies and when I search for a class (by hitting ctrl-N ... go figure) I frequently don't get any results. Some kind of misconfiguration will silently make things not work. It happens enough that I have to second-guess its results, even when they're correct. Now I only use ctrl-N to jump back and forth between classes I know exist. Actual searches I'll leave to find/grep/ag.

Likewise when I optimistically right-click some part of my project and click 'Run all tests'... "No tests were found".

Regarding Intellij and looking for classes / running test: I think this mostly depends on whether you're casually browsing some random project, or if you're gonna work on the same project for several weeks.

It's fine to try to open the random project in your favorite IDE and see if it just works. If it doesn't, and you just need to figure out what the code does, fix a few lines of code, going back to a text editor, grepping and trusting the CI to run the tests itself is just less overhead.

If you work on the same project for a longer period of time, you can easily justify the upfront cost of configuring your environment properly (and have your class searches and 'Run all tests' running).

On top of that, his opening example is so easy if you use a GUI for Git it's mind-boggling.

It'd literally be click status column to sort, click top entry, shift-click bottom deleted file, right-click, restore. Done, a couple of seconds without even thinking about it.

And somehow this simple task in a GUI inspired a blog post about how useful the shell is.

I'm not going to deny a shell is extremely useful, and knowing far more than I do makes you a better programmer, but there's also using the right tool for the job.

> Done, a couple of seconds without even thinking about it.

This was originally done in a couple of seconds without deeply thinking about it (hence originally using grep instead of `awk '/re/'`).

(Edit: quote)

That relies on there being a sufficiently versatile gui which isn’t guaranteed. Here’s some features that your example requires which I often don’t see in guis:

1. Tables you can sort

2. Tables you can sort on the thing you actually care about

3. Being able to select multiple entries and act on your selection

It’s not too hard to imagine criteria which could make the problem much harder for a gui, e.g. only doing the operation in a subdirectory (if the sorting is stable this isn’t so bad), or only on files not in a subdirectory (stable sorting won’t help here, you’d need the gui to let you eg search for / and then remove those things from your current selection), or only operating on .h files (you’d need a search->select feature again), or doing an operation that the gui doesn’t support on multiple files, or passing the list to some other tool (maybe you want to search makefiles for references to the deleted files).

Something that a gui may be able to handle but that often screws up shells would be file names with newlines or spaces in them.

In the end, your are gonna write regex either way :D

It might not be hard to imagine it, but it's not actually that common an occurrence.

When's the last time you accidentally delete 200 files and needed to restore them? Probably because you were using a shell...

Oh yeah, and if you accidentally delete folder in a GUI? Usually you can just press ctrl-z, undo!

The point of the article clearly is about how a few general purpose shell tools can combine together to be the "right" tool in so many different usecases for which they weren't specifically designed for. You can argue for more specialized tool, and that's okay. But saying just "this" task inspired this blog post clearly misses the point of the article, which is generality.

In any case there are like a bazillion of GUI git tools. Are you certain each and all of them support this feature? If someone doesn't know any of them, what are the odds the first GUI tool they install has this feature? The hidden cost of finding the "right" tool is overlooked in its advocacy.

And there are a bazillion CLI tools, you can't use that defence.

Now do it across 5 projects. Or help explain to all your teammates how to do it.

With the shell, the second time you do it is a few keystrokes, if even. Wanna do it across multiple projects, it’s super easy without ever loading any of them in your IDE.

Wanna share it with teammates, you simply need to pass a script file to them, and they can do it without having to do anything.

And now finally if you need to incorporate this behavior in your headless CI? It’s the same script, instead of having to putz about with the CI configurations or whatever.

a) It's not a common task

b) a few keystrokes === a few clicks

I strongly agree with this narrative and it matches my own experience. I spent 9 years of college and then grad school using exclusively either vi or emacs because I believed IDEs were a crutch that weak engineers relied upon. It wasn't until I got a real job that I found myself forced to learn a proper IDE (IntelliJ).

It blew my mind just how powerful the IDE was and how it massively increased my productivity. Putting aside code completion and code generate, I found it much easier to navigate a codebase using a proper IDE that fully understood the language. When I contrast that to my previous solution, a highly customized emacs configuration with lots of packages and my own functions, the two just don't compare.

I think part of this is that the people who use IDEs then prefer the actual code to be dumbed down to the point where the IDE can both understand it and then is required to manipulate it; I hate programming in Java because it is a language kind of designed to make it hard for me to build my own rapid abstractions... which of course would break the ability of the IDE to parse it at all much less refactor it; but, I then argue that the more powerful code abstractions obviate the language flaws that required "refactoring" in the first place. And to me, that is a way in which I feel like IDEs are awkward and harmful, but it is almost more at an ecosystem level than at the scale of a single person.

You have it totally backwards, people who use IDEs don't like "dumbed down code" for the sake of the IDE. Nor are languages like Java designed with their IDEs in mind. The IDE is designed with the full language spec in mind, understands the language at the AST level and supports the full set of language features and all their permutations. A developer who is writing code in IDE is utilizing every permutation of what the language provides and it is upto the IDE to understand it.

IDEs for the most part are not covering for language flaws, they are helping developers be more productive by removing the need to focus less interesting parts of the process and focus on the the problem being solved. While the need for an IDE is more important in some languages over others, there are a set of common problems that exist in every language that the IDE can help solve (navigating the codebase by jumping around to symbol definition/usages, auto importing packages/modues, intellisense, refactoring).

Refactoring does not mean going back and refactoring 6 weeks worth of work that you seem to have in mind. Most people who refer to refactoring are referring to it in the context of multiple small refactors during very short development cycles (every few minutes or hours). My workflow and the workflow of many developers I have worked with goes like this:

* Write some code (not more than 200-500 lines)

* Write tests

* Refactor if needed- potentially rename variables, potentially extract some code into methods, potentially pull stuff up into constants, potentially introduce a new class or interface, potentially change types of certain members, potentially visibility of certain members or methods.

* Repeat for the entire workday when you are not in meetings.

Refactoring- specifically the kind of small scale refactoring that you do as go through your workday to me is almost as important a part of the development process as anything else and IDEs remove almost all friction from it by removing any cognitive load of the task from the developer.

Which powerful language do you use that can't be understood by the IDEs. Don't you think that if your compiler can understand it, the IDE can too? :)

I've found that IDEs work well when you're working within a single language or framework, but are clunky for multi-language projects. It's easier for me to have 4 terminals open (2 for vim, 2 for execution) than two different language-aware IDEs. With the IDEs, I need to pay attention to which IDE I'm in since they have different shortcuts and UIs.

Which languages do you mix and match that something like IntelliJ IDEA can't support?

Opening a shell is not an obstacle when you've already got several open. Also, not all of us are refactoring huge codebases or using verbose languages that require a lot of handholding. The hard part of development is typically not at the typing or syntax levels, and I have the stdlib of my favorite libs close to memorized already. The most helpful ides tend to be massive as well.

Tools can be useful however, such as the hot reload of flutter/dart. That's the kind of improvement I really appreciate.

Regarding the hat part not being the typing - yes!

Every tool, plugin or functionality takes up some space in my mind. Once I know the tool really well, that space becomes smaller and the benefit of having the tool outweighs the cost. This is why I only add tools and plugins slowly. One at a time, only after I mastered it I add something new. And I weed out my tools from time to time and remove things I don't use often enough.

Maybe the people who use feature rich IDEs just have more RAM and a more parallel brain, and the CLI people have serial brains :D

It wasn't clear from your comment if you're aware of this, but Flutter hot-reload works from the command line too! I do all my Flutter development in 3 windows (vim, `flutter run` shell, android emulator).

Glad to hear, I've barely started with it.

> they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant.

I do this in stock vim using ctags files. You can generate them with anything, though “exuberant ctags” is very popular. Ctrl+] when over an identifier jumps to its definition, and there’s a tag stack to jump backwards similarly (you can also use the jump list). This too, is instant. It’s also an essential feature of the help system in vim for navigating cross-references.

There’s also other robust IDE-like features built-in. Syntax-aware code folding (with adjustable fold levels, see ‘folding’), compiler integration so that it’ll highlight where compilation errors occurred (see :make, makeprg, errorfmt) and so forth. Not saying your life won’t be better without some plugins, but stock vim is quite a bit more powerful than having to shell out and grep.

The point of IDE is that there is almost 0 configuration. You get everything by just clicking "install". Y you can configure vim or emacs to be as expressive as IntelliJ. But the time it takes is much larger than 0. And when you switch to another language you'll probably need to repeat many steps.

The point of the OP is to not configure vim or emacs to do all that but to simply use the UNIX (or platform equivalent) shell.

I've been using a lot of typescript lately. The ide support in vscode/tsserver is very complete, but it is NOT fast. As an example, it frequently takes multiple minutes to use find references. Rg or git grep with fzf are both hundreds of times faster, and are easier for me to navigate. (Obviously language aware find references is much more powerful, but with carefully named variables it's acceptable to just use rg.). Sometimes, even a simple "go to definition" results in a 45 second hang. (This is on a 2019 Macbook pro)

I've also used intelij idea with Java, and while it was much smoother than anything in the typescript ecosystem, it's definitely not faster than using grep.

> 1000x faster than opening a shell and trying to...

Not commenting on who is right or wrong, but there is a key difference in your workflow here. OP is not opening a shell at this point. The shell is the first thing being launched, vim is secondary.

> The difference is like using a hammer vs using a nail gun.

I feel like this metaphor falls short.

The IDE, IMHO, is more like a multi-tool with pre-chosen use cases, but everything fits together nicely.

Using the shell is more like choosing the exact tools for the job, and maybe connecting them together in a make-shift fashion.

Yup, like having a 9-in-one painter's tool vs having those 9 tools individually in a toolbox.

Usually, its super convenient to have all those tools integrated because you can scrape some paint and pound a nail and pull a nail all right then and there with needing to do any swapping out or hunting for the right tool.

But the instant you want to be able to hold a bolt in place with the wrench function while simultaneously using the hammer function, you're shit out of luck. The painter's tool, on its own, can't be de-composed to do those things simultaneously. Plus, it's not as good at being a general purpose hammer or a general purpose wrench. But in the context of the tool, you don't really need a full fledged hammer or wrench. Having a single small tool you can hold in one hand is usually more pragmatic, even if less versatile.

Probably still gonna want the toolbox to be available for when you need it, though.

How do you refactor, say, Java or C# or Typescript with Vim?

These days, language servers and wiring up one of the clients in Vim.

Have you used them? Are they reliable/stable/fast? Easy to configure?

Sounds like a reinforcement of Drew's point to me. Using the IDE to jump all over the place, and blast changes over several files at once, suggests severe and unnecessary non-localities and tight couplings in the code.

Maybe without the IDE, the code would have ended up a little cleaner.

> Maybe without the IDE, the code would have ended up a little cleaner.

When you can’t easily jump from file to file and get intellisense like completion you are forced to design modules and data models which can fit inside your head. I imagine this can be a feature in some cases and a limitation in others.

I tend to only use an IDE when refactoring, and a text editor for everything else. So far I haven’t had to write or work on code which I can’t keep all in my head; maybe I have just been lucky with the codebases I have worked on?

> I imagine this can be a feature in some cases and a limitation in others.

Technically true, but it's only a limitation in the sense that not being allowed to use asbestos shingles and lead pipes is a limitation for someone building a house.

A big part of the reason I gravitated toward Emacs is that it hits the best of both worlds there; by default, it's a simple editor, but it can be extended with the exact set of IDE-esque features with which I'm comfortable.

> take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was.

Know any C/C++ IDE that would do this? I transitioned from Qt Creator to VSCode and none of those have helped me with this cool nicety you mention.

EDIT: I should add that for me, exploring foreign code bases has been hugely improved since I discovered Sourcetrail, so I'd suggest having a look at it to anyone interested in code exploration tools: https://www.sourcetrail.com/

I've found Jet Brains' CLion to do a solid job of code navigation, but I don't currently work in C/C++ and only use it occasionally for reading code bases.

I do use Jet Brains other editors and Intellij has flawless Java code navigation (among other amazing features). Further, I've found PyCharm provides Python code navigation that is about as good as possible for such a dynamic language. Therefore I'd expect CLion to provide top notch code navigation for C/C++.

vim can definitely do it with CoC

Visual studio code can do this.

https://stackoverflow.com/questions/35424367/how-to-navigate...

> Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant.

Vim can do this too and (rip)grepping the code is only needed if you're looking for, you know, text. I have 'gd' mapped to "go to declaration" and 'gr' to "find references". Works across dozens of languages, can be further scripted upon. Basic refactoring (renaming class method in several files) should also work, but I use it so rarely that actually can't testify about it (I use rope bindings for python refactoring but it's usually limited to a single file).

It's not as honed as purposely built 5GB IDE of course. But having one editor for all languages and syntaxes is really nice. Things like VSCode have this one too, but I wouldn't call them and IDE either.

I haven't been using IDEs any meaningful amount of time as I'm not a developer, but if the things you mentioned (go to definition, changing names) are the main reasons for an IDE, one could argue that terminal workflow has substantial benefits, like better understanding of the toolchain, simpler integration with ci/cd tools, endless customization, single tool across languages and other standard cons of CLI tools.

I do, however, find vim without extensions useless for editing code as well.

I agree.

But it's worth pointing out that IDEs provide depth for working on a given project. If you want to provide breadth across many projects (like writing a custom linting script), you do want to be she'll literate. Not every automation task can be specified in with grep and such, but quite a number of them can. And the ones that can't be written in terms of the shell often benefit from hybrid solutions that combine shell tools and specialty tools like parsers.

Nah, the issue is that whenever the IDE doesn't provide a shortcut for whatever you're back to negative one. That's why people like mechanisms (grep, sql or similar) over policies (here, whatever is given to you by the IDE), you can always adapt.

Other than that, a good deal of open mindedness and skillful use of IDEs is not a bad trait. Let's not be extremists.

> Nah, the issue is that whenever the IDE doesn't provide a shortcut for whatever you're back to negative one.

You are not back to negative one, more like you are at square 85. There is nothing stopping a developer from supplementing something that the IDE doesn't easily support. For example I use PyCharm these days and I when I make a change to a file I automatically want the test associated with that file to run- this is not supported in PyCharm (or atleast I don't know how to get PyCharm to do it) so I wrote a script that runs in the background of my shell watching for changes on files on my project and running appropriate tests.

The point if an IDE doesn't have a quick way of doing something that is necessary for your workflow, it doesn't mean that the 20 other things that the IDE does are useless. Any working developer should continue to be able to extract value from the features that the IDE provides and jump back to fill the holes themselves (via shell scripts or what have you) instead of saying "Whelp this means IDE is a crutch now and I must revert to only using 'Unix as IDE' and only relying on sed/awk/grep and friends" to aid my development workflow.

Maybe I was traumatized by eclipse. Anything to extend in it required a federal reunion and a taskforce.

The two worlds of editing general purpose text files, when compared to editing a large amount of a very specific kind of text file, look very similar.

I’ve never seen advocacy for one over the other as a competition. I do plenty of both types of editing, and often edit the same files simultaneously with three different tools.

(Example: Editing notes in Notable, Atom, and vim.)

I'd also argue that it's helpful to understand the technology underlying your IDE, if only to be able to debug builds. (Understanding that MSBuild exists, and can be called from the command-line, for example, is a handy skill).

Those tools are all great and I have that in Vim but I also have the whole shell environment to do many other things that have nothing to do with the content of the code.

For scriptable editors the difference is more like giving you a home depot vs a multi-feature nail gun. There're option to use other people's scripts (buy nail gun directly), or script yourself (buy parts and build your own nailing tool that suits your need, but do need to invest time in learning and building).

A literary man creates new meaning out of words. You can do this in the shell by combining tools in new ways. You can not do this easily with an IDE, it only has a predefined meaning. Using an IDE is not literature but transcription.

Well, 95% of software development is writing invoices, not poetry, so...

This speaks more to the narrowness of your view than it does about shell.

Example: I work with parallel filesystems quite a lot. Often I will need to parse through GB of logs spread across a cluster to track down a particular sequence of events for troubleshooting.

I could load up a fancy IDE with all the bells and whistles, one that instantly refactors all my 'foo', and still spend a (very) non-trivial amount of time carefully crafting (and documenting, and debugging) a proper application to solve the particular problem I'm working on.

OR - I could rattle off a pipeline using a few general tools and get the needed details in less than a minute.

You analogy about hammers is particularly amusing, invoking the old saw "If the only tool you have is a hammer, every problem looks like a nail". You take this to the absurd degree that you end up championing nail guns!

> "parse through GB of logs spread across a cluster" Why would you do that with IDE?

The OP is comparing IDE v.s. shell in terms of "exploring" and "editing" the code. In that case IDE is a powerful nail gun and championing it isn't wrong.

Reply on news.ycombinator.com