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 c

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.