3 ms·

There are many parts to answering this. First, "plain" text editors have caught up with IDEs in many ways that you're talking about here. With a good LSP plugi

There are many parts to answering this. First, "plain" text editors have caught up with IDEs in many ways that you're talking about here. With a good LSP plugin, you can hop to definition and autocomplete perfectly fine. For a strong statically typed language, the editor can even tell you why it won't build and how to fix it before you even try. Many things you used to need an IDE for just no longer require it. Second, even without those tools, people hacking away at a keyboard are often doing a lot more than just writing executable code. You're editing config files, READMEs, comments, documentation templates, test data, API request examples. None of these things are amenable to any of the niceties an IDE can help with. Third, in a microservices world or even just working on a plain library that calls into lots of other libraries, unless you download the source code for every dependency, hop to definition and autocomplete isn't guaranteed to work anyway. It's often easier to pull up the API documentation in a browser on a second monitor and refer to it while working. Screen real estate is cheap these days and the more mature projects you're better off using as dependencies anyway tend to be pretty well documented. Fourth, an increase in the use of dynamic languages has brought with it an increase in dynamically-generated code. There's a lot of convenience here in reducing the amount of boilerplate you need to type out and being able to change behavior without even having to rewrite the core code, but it also makes IDEs less useful. It pushes the mental burden of understanding how code gets generated and runtime objects get decorated and changed by understanding the underlying data model of the language and its runtime, but hey, that's what we're paid for. Fifth, what does it even matter in the grand scheme to have definitions and names more readily available inside the actual window you're typing into? It's a convenience, sure, but if you type subst when it should have been substring, you try to build or run a test or just a static analyzer or whatever and you get an error message and remember "oh yeah, that's Language X and I'm writing Language Y," you lost what? A minute at most to go do a global find and replace? Compared to the time studying a problem domain, designing and vetting a solution, coming up with adequate test cases and a suitable type representation that models the domain, the time spent literally typing out function names is minuscule. I'm not going to say saving seconds there is worthless, but it's not a huge gain.

Guid_NewGuid 5y ago
I'll try and respond to your points but hopefully without omnislashing. On 1) I think that's why this post in particular triggered the question. I don't even conceptually understand what vim and emacs are. Like there are terminal buffers, there's an editing mode, you can't quit it without knowing some arcane ritual and org-mode is, like, wikipedia for to-do lists or something. These are very powerful pieces of software with programmability and plugins supporting e.g. autocomplete that bring them most of the way to an IDE. Nano on the other hand I have used when I need to edit some configs or files on a server and I am just absolutely bewildered at the idea anyone would do more than light text editing in it. Which kind of leads in to the second point but not really. I prefer a specialised tool for each of those, where applicable. Like README or documentation I might use VS Code with Markdown preview or MarkdownPad2. For config files/hand crafted requests I might just use Notepad++ but increasingly VS Code fulfils this role too and will let you know if you've made a syntax whoopsie in a lot of file formats. For the third I've actually found I prefer a single 13" monitor with a single window for programming. I feel like looking at API docs in a browser is just enough of a context switch that it will break my focus versus auto-completing to victory. I can actually remember the last time I looked at an API doc in the browser because it was today and I wanted to make a nerdy joke but didn't have the IDE open and couldn't remember if the method was WaitAsync or Enter. But otherwise I will use API documentation once in a blue moon. Most API documentation I just don't find helpful and since we rely on a lot of open source libraries in my job a lot of it is porbably either bad or non-existent. Perhaps this is a difference between people who learned programming when one did it by consulting the BASIC manual and then figuring out and typing the code versus a more IDE based way of learning? I'd guess the BASIC generaiton learned programming more methodically and more deeply. On 4 my brain falls into this same trap of incomprehension with dynamic languages, though I'm interpreting this as dynamically typed which might be a misinterpretation. Re-reading I don't think that was the distinction you were making so I won't expand here. Lastly, I've personally found the overhead to be a lot higher. Since this is a throwaway account I can't link to the PR but I recently did some JavaScript work in a big codebase in a text editor and even writing a fairly simple 50 line method felt like swimming through treacle. Not knowing what I had defined, what I could do with what was defined, where I'd used something that was just defaulting to global since it was undefined, where I'd made an obvious syntactic error etc. I'd say (for me on that codebase) the slowdown to my personal productivity was between 3-10x. Granted that was a codebase without tests, a linter set up, etc. and with low personal familiarity with JavaScript and working efficiently in raw text-editors but it's not an experience I ever want to repeat. Even with tests the time to run the tests, parse the test output, translate the error message and then apply the corresponding fix (and write the test in the first place) versus just fix what the red squiggly told you just seems intentionally less productive. An additional 'finally' as a mea-culpa. I once tried to learn Pony since the language seemed interesting but every time I tried I just bounced off it because I felt so lost and unproductive having to use the API docs and tests/compiler workflow. People who are more used to that workflow probably have an easier time picking up new languages and codebases so while in my experience I'm in the top 20% of people in my language I have a poor generalist ability and low efficiency outside my specialization.

Guid_NewGuid 5y ago

I'll try and respond to your points but hopefully without omnislashing. On 1) I think that's why this post in particular triggered the question. I don't even conceptually understand what vim and emacs are. Like there are terminal buffers, there's an editing mode, you can't quit it without knowing some arcane ritual and org-mode is, like, wikipedia for to-do lists or something. These are very powerful pieces of software with programmability and plugins supporting e.g. autocomplete that bring them most of the way to an IDE. Nano on the other hand I have used when I need to edit some configs or files on a server and I am just absolutely bewildered at the idea anyone would do more than light text editing in it. Which kind of leads in to the second point but not really. I prefer a specialised tool for each of those, where applicable. Like README or documentation I might use VS Code with Markdown preview or MarkdownPad2. For config files/hand crafted requests I might just use Notepad++ but increasingly VS Code fulfils this role too and will let you know if you've made a syntax whoopsie in a lot of file formats. For the third I've actually found I prefer a single 13" monitor with a single window for programming. I feel like looking at API docs in a browser is just enough of a context switch that it will break my focus versus auto-completing to victory. I can actually remember the last time I looked at an API doc in the browser because it was today and I wanted to make a nerdy joke but didn't have the IDE open and couldn't remember if the method was WaitAsync or Enter. But otherwise I will use API documentation once in a blue moon. Most API documentation I just don't find helpful and since we rely on a lot of open source libraries in my job a lot of it is porbably either bad or non-existent. Perhaps this is a difference between people who learned programming when one did it by consulting the BASIC manual and then figuring out and typing the code versus a more IDE based way of learning? I'd guess the BASIC generaiton learned programming more methodically and more deeply. On 4 my brain falls into this same trap of incomprehension with dynamic languages, though I'm interpreting this as dynamically typed which might be a misinterpretation. Re-reading I don't think that was the distinction you were making so I won't expand here. Lastly, I've personally found the overhead to be a lot higher. Since this is a throwaway account I can't link to the PR but I recently did some JavaScript work in a big codebase in a text editor and even writing a fairly simple 50 line method felt like swimming through treacle. Not knowing what I had defined, what I could do with what was defined, where I'd used something that was just defaulting to global since it was undefined, where I'd made an obvious syntactic error etc. I'd say (for me on that codebase) the slowdown to my personal productivity was between 3-10x. Granted that was a codebase without tests, a linter set up, etc. and with low personal familiarity with JavaScript and working efficiently in raw text-editors but it's not an experience I ever want to repeat. Even with tests the time to run the tests, parse the test output, translate the error message and then apply the corresponding fix (and write the test in the first place) versus just fix what the red squiggly told you just seems intentionally less productive. An additional 'finally' as a mea-culpa. I once tried to learn Pony since the language seemed interesting but every time I tried I just bounced off it because I felt so lost and unproductive having to use the API docs and tests/compiler workflow. People who are more used to that workflow probably have an easier time picking up new languages and codebases so while in my experience I'm in the top 20% of people in my language I have a poor generalist ability and low efficiency outside my specialization.