VSCode is not an IDE, it's an extensible text editor. IDEs are integrated (it's in the name) and get developed as a whole. I'm 99% certain that if you were forced to spend a couple of months in a real IDE (like IDEA or Rider), you would not want to go back to vim, or any other text editor. Speaking as a long time user of both.
I get your point, but VSCode does far more than text editing. The line between an advanced editor and an IDE gets blurry. If you look at the Wikipedia page about IDEs[1] you see that VSCode ticks off more boxes than not. It has integration with source code control, refactoring, a debugger, etc. With the right combination of extensions it gets really close to an IDE as strictly defined. These days advanced text editor vs. "real" IDE seems more like a distinction without much of a difference.
You may feel 99% certain, but you got it wrong. I have quite a bit of experience with IDEs, you shouldn't assume I use vim out of ignorance. I have worked as a programmer for 40+ years, with development tools (integrated or not) that I have forgotten the names of. That includes "real" IDEs like Visual Studio, Metrowerks CodeWarrior, Symantec Think C, MPW, Oracle SQL Developer, Turbo Pascal, XCode, etc. and so on. When I started programming every mainframe and minicomputer came with an IDE for the platform. Unix came along with the tools broken out after I had worked for several years. In high school I learned programming on an HP-2000 BASIC minicomputer -- an IDE.
So I have spent more than "a couple of months in real IDEs" and I still use vim day to day. If I went back to C++ or C# for Windows I would use Visual Studio, but I don't do that anymore. For the kind of work I do now vim + ctags + ripgrep (and awk, sed, bash, etc.) get my work done. At my very first real job I used PWB/Unix[2] -- PWB means Programmer's Work Bench -- an IDE of sorts. I still use the same tools (on Linux) because they work and I can always count on finding a large subset of them on any server I have to work with.
I don't dislike or mean to crap on IDEs. I have used my share of IDEs and would again if the work called for that. I get what I need from the tools I've chosen, other people make different choices, no perfect language, editor, IDE, what have you exists.
The HP 2000 [1] had a timeshared BASIC system that the school district made available to schools, over ASR-33 teletypes with dial-up modems. The BASIC system could edit, run (translate to byte code and execute), manage files. No version control or debuggers back then. The HP 2000 had another layer of of the operating system accessible to administrators (the A000 account if I remember right) but it was the same timeshared BASIC system with some additional commands for managing user accounts and files.
No one familiar with modern IDEs would recognize the HP 2000 BASIC system as an IDE, but it was self-contained and fully integrated around writing BASIC programs. HP also offered FORTRAN for it but not under the timeshared BASIC system. A friend wrote an assembler (in BASIC!) and taking advantage of a glitch in the bytecode interpreter we could load and run programs written in assembly language.
After high school I got a job as night computer operator with the Multnomah County ESD (school district) so I had admin access to the HP 2000, and their two HP 3000 systems, and an IBM computer they used for crunching class registrations. Good times.
Someone had an emulator online for a while, accessible over telnet, but I can't find it now.
i think it's very reasonable to describe time-shared basic systems like that as ides. the paradigmatic example of an 'ide' is probably turbo pascal 1.0, and of the features that separated turbo pascal from 'unintegrated' editor/compiler/assembler/linker/debugger setups, i think the dartmouth timesharing system falls mostly on the 'ide' side of the line. you could stop your program at any point and inspect its variables, change them, evaluate expressions, change the source code, and continue execution. runtime errors would also pop you into the interactive basic prompt where you could do all those things. i believe the hp 2000 timesharing basic had all these features, too
At the time, in the context of other software development environments (like submitting decks of punch cards) the HP 2000 timeshared BASIC environment would count as an IDE. Compared to Turbo Pascal or any modern IDE it falls short.
HP TSB did not have a REPL. If your program crashed or stopped you could not examine variables from the terminal. You could not peek or poke memory locations as you could with microcomputer BASICs (which didn't support multiple users, so didn't have the security concern). You had to insert PRINT statements to debug the code. TSB BASIC didn't have compile/link steps, it tokenized the code as you entered the lines, and the interpreter amounted to a big switch statements on the tokens. P. J Brown's book Writing Interactive Compilers and Interpreters (1981) describes how TSB works. Eventually I got the source code to TSB (written in assembler) and figured it out for myself.
Other BASIC implementations that popped up around the same time had richer feature sets. In my senior year at high school I got (unauthorized) access to a couple of Unix systems in Portland, ordered the Bell Labs Technical Journal issues that described Unix and C, and taught myself from those. I didn't get paid to work on a Unix system until several years later (detours into RSTS-11, TOPS-20, VMS, Microdata, Pr1me, others) but I caught the Unix and C bugs young and I still work with those tools every day.
Some programmer friends and more than a few colleagues over the years have made fun of my continued use of what they call obsolete and arcane tools. I don't mind, I have never felt like I did less or sloppier work than my co-workers, and my freelance customers don't care what I use as long as I can solve their problems. Most of the work in programming doesn't happen at the keyboard anyway. I do pay attention and experiment with all kinds of tools but I usually end up going back to the Unix tools I have long familiarity with. That said I did spend many years in Visual Studio, MPW, CodeWarrior, and MPW writing C and C++ code, and I do think those tools (well, maybe not MPW) offered a lot of benefits over coding with vim and grep, for the projects I did back then.
Maybe ironically I use an iPad Pro, I don't have a desktop or laptop anymore. So I have the most modern hardware and a touch-based (soon) AI-assisted operating system that runs a terminal emulator during my work time.
thank you! i didn't realize that it lacked the features of the microcomputer basics; i have the impression that they were copying the same dartmouth timesharing system that hp was copying, but of course i've never used dtss myself
what kind of obsolete and arcane tools do you use? vim seems to be pretty popular among the youngsters these days. a friend of mine a bit younger than you prefers ex
My usual programming toolbox includes vim, ctags, bash, rg (or grep if I have to), sed, awk, tmux (or screen), git, and usually a CLI for one of MySQL, PostgreSQL, SQLite, Redis. The only vim plugins I like to have: ctrlp (file fuzzy finder) and advanced text motions.
On the iPad I use Blink shell, the Github client, Apple Notes. I always have a paper notebook and pen, my short-term memory gets less reliable every year.
I have noticed a lot of younger people using or at least learning vim and CLI tools, maybe retreating from the complexity of modern software development setups. Maybe just a retro fad, I don’t know.
I also see terminal setups described online that try to reproduce the GUI experience — lots of colors and planes and widgets. Neovim and zellij both look like that to me — a lot of extraneous functionality and visual clutter that mimics VSCode. I prefer a more minimalist environment. I don’t even use syntax coloring.
Everyone has to find the tools that work for them, that takes time. I think most programmers figure out at some point in their career that continually experimenting and polishing their tools doesn’t always help get the work done, and when you freelance you get more conscious of billable vs. non-billable time.
i think you're mostly more modern than i am, despite being much older. i generally use grep rather than rg, screen rather than tmux, emacs rather than vim for programming (though i use vim on my phone and for writing email), no redis, no fuzzy find, and no ipad. the only differences in the opposite direction are that i usually use python or perl rather than sed and awk, and i do use syntax coloring—for me, terminal colors were one of the big pluses of moving from sunos 4 to linux
i don't think younger people using vim is a fad, but we'll see. vim to me, especially neovim, seems mostly like emacs in vi clothing
I think you're arguing semantics here in a way that's not particularly productive. VSCode can be set up in a way that is nearly as featureful as an IDE like IntelliJ IDEA or Eclipse, and the default configuration and OOB experience pushes you hard in that direction. VSCode is designed for software development, not as a general text editor; I would never open up VSCode to edit a configuration file or type up a text file of notes, for example.
Something like vim is designed as a general text-editing tool. Sure, you can load it up with plugins and scripts that give you a bunch of features you'd find in an IDE, but the experience is not the same, and the "integrated" bit of "IDE" is still just not there.
(And I say this as someone who does most of his coding in vim, with LSP plugins installed, only reaching for a "proper" IDE for Java and Scala.)
One metric I would use: if I can sit down at a random co-worker's desk and feel more or less at home in their editor of choice, then it's probably an IDE that has reasonable defaults and is geared for software development. IDEA and VSCode would qualify... vim would certainly not.
