I can’t tell you how many times my use of very vanilla Emacs with zero jedi / autocomplete / search features has saved me in my career.
It’s so critical to use text editors for software development and extract all other functionality to separate shell tools.
If a mix of very simple vim or Emacs + grep / git grep / silver searcher + CLI tools for automatic linting, test cases, etc., isn’t efficient for you, and motivates you to bring all these things into one consolidated IDE, I urge you to consider that this is a type of bad code smell and bad workflow smell, the all-in-one IDE is not actually helping productivity but hurting it in the long run, and you should invest right away in the learning curve & barriers you perceive are blocking you from a purely shell command-line workflow that separates code management & search into isolated utilities in separate interfaces.
I do grant there are a very small number of use cases where the IDE approach is useful: helping students who are literally just starting out, helping developers with atypical accessibility constraints that can be assisted with the IDE, probably a few more.
But general code search, linter/test integration, and embedded features like autocomplete, pop-up signatures or docs, etc., are disastrously bad things hands down for regular development.
It’s such a shame that a whole generation of programmers are tricked into believing those things are good for them.
It reminds me of people tricked into becoming reliant on MATLAB or Jupyter notebooks, and then retroactively trying to defend those tools as productivity-enhancing when they are, from first principles, productivity destroyers.
Comments like this were part of the reason I wasted a lot of time earlier in my career trying to use emacs or vim on large code bases instead of an IDE.
I suspect this is some tribal identity thing about being a “real” programmer that I fell victim too.
The IDEs are extremely powerful and much better out of the box for working in a large code base. They allow you to navigate a lot more easily and focus on the code itself rather than constantly having to deal with your setup.
Don’t let comments like the parent scare you away from them.
I know a couple of people holding the same opinion as OP. Can't say they are more productive.
The percentage of people that are hard to work with is higher in this group though.
And I know, what I'm talking about here. Started with a Commodore 64 in 1982, first Linux 1994. Did everything in emacs, calculated mode lines, Unix was my IDE, you name it.
I'm a very happy user of CLion and IntelliJ IDEA now. Wouldn't want to go back to the dark ages.
> “I know a couple of people holding the same opinion as OP. Can't say they are more productive.
The percentage of people that are hard to work with is higher in this group though.”
This seems more telling about your attitude towards this subject, and perhaps also lesser skill in assessing or understanding those productivity differences.
Use what works best, but Emacs is incredibly powerful, and certainly has the potential to make you more productive. I wish I had taken the time to learn Emacs earlier in my career, my task efficiency has increased significantly since converting my work flows.
It does take a long time to learn relative to plug and play solutions (especially for someone like me with decades of old habits), luckily I had a few months off from work for the transition. The investment has been well worth it, it helps if you like lisp :)
Disclaimer: I use and advocate for tools derided above: linter/test integration, embedded features like autocomplete, etc.
Yeah, that was the bit that got me. Emacs is in many ways the original IDE; insisting that people not use things like method signature hinting feels vaguely perverse.
Method signature hinting and other forms of autocomplete-like functionality are very actively harmful to productivity and prevent you from holding a mental model of the codebase. The larger the codebase, the worse this effect gets and the more critical it is to only approach writing code when you’ve got a sufficiently burned in mental model of the subsystem you’re dealing with, by searching and reading code with tools & interfaces wholly distinct from what you use for writing code.
It’s like the difference between someone who can navigate the highway system with interstate signs & atlases alone vs someone who is unable to navigate at all without a GPS system.
Even if the GPS system experiences no downtime, they still lack skills that make the driving lower quality, like anticipating changes or adjusting for weather.
Coders heavily reliant on IDE tools simply understand the ramifications of what they are writing less well, because they haven’t invested in the mental map of the code and mistakenly believe they can safely offload many parts of that cognitive requirement to an IDE.
Worst of all, they believe that code shipped this way is somehow reinforcing evidence that the IDE was a value additive tool, which is the wrong counterfactual for comparison. You have to consider the value lost from what better solution could otherwise have been shipped for lower cost using a different set of tools.
> But general code search, linter/test integration, and embedded features like autocomplete, pop-up signatures or docs, etc., are disastrously bad things hands down for regular development.
Many years of experience leading software teams and watching these tools hold back younger engineers time and again. Random breakages, surprise integration quirks, facilitating confusion of the design principles in the underlying code they only see through the IDE, inability to do necessary work in environments that can’t support the IDE (like during an outage that requires access to a different environment for a change). It’s been one of the most common patterns of lost productivity I’ve seen in my career, across many companies and many cohorts of engineers that would control for virtually any confounders, leaving me only to believe it’s the principle of using IDE assistance for these things.
Indeed - and those investing in higher-level languages such as assembly or C (gasp!) are tricked into believing those things are good for them - when really, they should be investing in learning machine languages, the purest form of programming for general-purpose processing circuits. /s
Honestly, programming languages, IDEs, Jupyter notebooks, etc. are all tools to help individuals solve problems using general-purpose processors. If you feel equally productive without some of those tools, that's fine, but there's nothing wrong with using those tools if they help.
i was initially confused, why would you want to jump or even convert between the '<' and '>' signs? but from trying it out on that snippet, '%' actually jumps to the nearest bracket and selects(?) the matching one [0].
now, i'm not 100% sure on the exact behaviour, but e.g. even a cursory test in sublime shows it will highlight the start and end brackets if i'm inside the if-expression and you can "expand selection to brackets".
> But general code search, linter/test integration, and embedded features like autocomplete, pop-up signatures or docs, etc., are disastrously bad things hands down for regular development.
I honestly can’t tell if this is a spoof “ how hackernews can I make it?” comment or not. What, precisely, is bad about those things? Would there be some virtue in my knowing every method signature in the enormous code base I work on from memory?
You are delusional and immature. I've seen experienced Vim/Emacs kiddies like you really struggle to keep up with my productivity levels in IDEA with JVM languages. Doing everything at the command line doesn't make you 1337 and superior. The actual typing and manipulation of text is the least complex side of development. Most of my time is spent thinking, analyzing, rather than monkeying with text. However I use Vim keybindings in IDEA and get the best of both worlds. Efficient text editing + advanced semantic parsing at a level that Vim and Emacs will never achieve.
If you actually read his comment, I think you'll agree this was an accurate and fair assessment. I've worked with those kids who believe they're super smart and others are simpletons purely based on tool preferences.
You don't have nearly enough information to draw that conclusion about someone from an internet comment. However, even if you're right, it misses the point. The point isn't that you owe $commenter better, it's that you owe the community better. Personal attacks poison the well and invite others to do worse. The community here is fragile. If you want to participate, you need to help preserve it, not help destroy it.
You're not just wrong, you're also rude, which is a sign of immaturity. Professionals try to avoid that kind of language.
If you never learned Vim to the sufficient level, you will never understand how incredibly empowering and powerful it is for navigating and editing text. And that IdeaVim is hopelessly lacking many of its features.
And if you never gotten in Emacs to the point of writing your own Emacs-lisp packages you will never learn true level of extensibility capabilities of Emacs. There's simply no other tool in existence that lets you do some borderline batshit crazy stuff.
When you don't know what you're talking about, at least have some respect for those who do. I personally used your beloved tools for about seven years (to the degree of above advanced level). I switched to Emacs (with Evil-mode), because I felt that I grew out of IntelliJ. Tell me about maturity.
It’s so critical to use text editors for software development and extract all other functionality to separate shell tools.
If a mix of very simple vim or Emacs + grep / git grep / silver searcher + CLI tools for automatic linting, test cases, etc., isn’t efficient for you, and motivates you to bring all these things into one consolidated IDE, I urge you to consider that this is a type of bad code smell and bad workflow smell, the all-in-one IDE is not actually helping productivity but hurting it in the long run, and you should invest right away in the learning curve & barriers you perceive are blocking you from a purely shell command-line workflow that separates code management & search into isolated utilities in separate interfaces.
I do grant there are a very small number of use cases where the IDE approach is useful: helping students who are literally just starting out, helping developers with atypical accessibility constraints that can be assisted with the IDE, probably a few more.
But general code search, linter/test integration, and embedded features like autocomplete, pop-up signatures or docs, etc., are disastrously bad things hands down for regular development.
It’s such a shame that a whole generation of programmers are tricked into believing those things are good for them.
It reminds me of people tricked into becoming reliant on MATLAB or Jupyter notebooks, and then retroactively trying to defend those tools as productivity-enhancing when they are, from first principles, productivity destroyers.