Comment by bitwize

Thank you for this post. By making it, you have attracted other people from Hackernews who've learned to "switch off the targeting computer". It helps to feel not alone.

So to answer your question, hmm.

I started programming -- well, I started programming the way many xennials did, in BASIC on an 8-bit micro. But when it came time to use "real" programming languages and environments -- your C++, your Pascal, etc. -- it was typically on DOS/Windows machines with an IDE. I became a Linux convert in 1995-1996 or so; I kept Windows around but just found myself wanting to use it less and less. So I had to think of Linux -- and, if possible, free software -- replacements for all of my favorite Windows programs including Borland C++ and Microsoft Visual C++, both of which were at the time roughly coequal tools for serious development on Windows. (It would take a few years for Microsoft to consolidate its developer tools into Visual Studio and then eat everybody's lunch with that.) So you know, Microsoft Paint had xpaint, and Photoshop had GIMP (still at version 0.54; you think it's rough now?!?) and Visual C++ had....?

The guy who introduced me to Linux in college was an Emacs advocate as well, and I'd heard of Emacs probably through Micro Emacs on the Amiga. So I decided to try Emacs (it had to be better than nano or vi[0]!) and learn how to use the command-line compilers and Makefiles as well, and these tools cobbled together would be the rough equivalent of Visual C++ with all its features. Note well that there was much less difference between a commercially available IDE and a text editor with a compiler bolted on in those days than there is today -- Visual C++ wouldn't get IntelliSense until 1997 or so[1].

So right from the jump -- before even trying Linux or Emacs or anything -- I learned how to wield APIs by studying the docs and remembering the names of things. Class, method, and function names to me were just like any other vocabulary. Just as you might learn the name of a new bird -- say the Spencer's Warbler -- but not just the name, the association between the name and what the bird does. So it goes with APIs. You learn that there's a function called CreateCompatibleDC, that it takes an HDC param, and what it gives you in return. If you're vague on any of the details (param type and order, return type, details of behavior) the docs are always a keystroke or click away. This was true even in Emacs which gave you a choice of two man page viewers, or you go to the web and look it up. Simple as.

Since learning to work well in Emacs, I have revisited IDEs from time to time and found them to be distracting. They don't have the features that I need. Even if they be extensible they make extending it to add those features difficult. And they give me a lot of features I didn't ask for or want. It seems like the IDEs are designed for corporate drones, to optimize standard applications being developed in standard ways. Even in the times I've been a corporate drone, never once has plugging forward in a standard workflow suited my needs[2]. I have always needed to write a bit of Emacs Lisp to help smooth out the kinks in my workflow -- running certain database queries, for instance, or monitoring and managing Docker containers for the app I'm working on -- and give access to all the weird little things I have to do on the daily to myself at a keystroke. Doing my coding in an IDE, for all the convenience afforded by some of their features, is full of friction, and I never reach that smooth fast state of flow the way I can in Emacs. I'm sure I could get faster by practicing in the IDE, but I'm always unsure if I would gain enough in productivity to justify the time investment in learning to do so. (Visual Studio Code, I know, is absolutely "not better enough" than Emacs to justify completely overhauling my workflow for it. There's still some doubt about IntelliJ for me in that regard.)

Go-to-definition is one of the few actual productivity enhancers modern IDEs give you, just from a standpoint of being able to walk a code base to find out what everything does as you study it. For most programming languages, it could be simulated with ctags/etags in vim or emacs since forever ago.

[0] Hail to my vi/vim brethren; vi was actually my first Unix editor and I still use it to this day. I found its modeful operation inconvenient in 1995, but today I don't see vi and Emacs as rivals, just two different approaches to achieving the same thing which is providing a flexible, real-time hackable development environment in contrast to the IDE/Visual Studio Code school which optimizes for standardized workflows and is absolute friction town for everything else.

[1] If you are unfamiliar with mid-90s software development, I recommend you go onto Internet Archive and look for old versions of Borland or Microsoft development tools, and install those in like a VM running Windows 95, 98, or 2000 just to get a feel for what they were like to use back then. They feel very bare bones compared to what we use today, yet large companies ran on client-server applications written in them.

[2] I've noticed this even in the Visual C++ days; Microsoft really wanted me to use the MFC library, and what I was writing at the time (a game for Windows 3.x) had absolutely no use for the "document/view model" or anything of that sort. The engine also didn't mesh well with how MFC handled events; and at the end of the day, the difference between event handling code done the MFC way ("message maps") and event handling code done the regular way (writing and registering a WndProc procedure for your window class) was really about the same, so MFC didn't really save me much. But if you committed to MFC, you could mash a button and skeleton out an app in an instant, and then it was just a matter of filling in the blanks. I felt I learned more, and could gain a bit of code efficiency, by writing everything myself.