[SvenL]

Interesting. I always hear "you don't need a full blown IDE, vscode/neovim/other text editor should be enough". Then I read those articles about which plugins/bundles/addons I need to install and I wonder at which point do we call it IDE instead of text editor (with plugins).

[serial_dev]

It heavily depends on the language, the frameworks and the actual project.

Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work.

Languages that have 3 decades of legacy warts, languages with no or poorly implemented LSPs, languages where the ecosystem relies heavily on runtime language features, frameworks that rely on behind the scenes magic and conventions, projects where for ten years the whole team only ever used one IDE… yeah, it’s not where vim/helix/vsc shines, and you will fight an uphill battle.

[The_Colonel]

> Languages that have 3 decades of legacy warts

Only languages with negligible market share don't have 3 decades of legacy warts.

[Asraelite]

Go, Rust, and Swift are currently at positions 7, 14, and 20 respectively on the TIOBE index.

[gf000]

Can we forget about Tiobe? It once listed Visual Basic ahead of JS, it's a dumb metric.

Nonetheless, I wouldn't write either of them without a proper IDE.

[serial_dev]

The Tiobe index might not be the best, but these are certainly popular languages and they don’t have decades, plural, of language warts.

Languages like Rust, Dart, Go, Kotlin, and Swift emerged when standard tooling was already expected, such as LSP, standard formatting and linting.

I don’t have experience with all of these languages, but I know that Rust and Darr have great tooling maintained by the same people who maintain the language and I can just pick any code editor with LSP support and I can expect the experience to be great.

[The_Colonel]

Yeah, cumulatively less than 5%.

[ghm2180]

> the frameworks and the actual project.

This.

e.g. Android studio has a great preview feature for composable which makes it a joy to build them. It gives you an option to run just see the live effects of updating code for that composable in (a) IDE (b) Emulator (c) Device.

[wiseowise]

> joy to build them

Requiring building app before having a preview and then waiting between 10 seconds to a minute on every change is what you call joy?

[rafaelmn]

> Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work.

The only language that comes to mind fitting this description is Go ?

[nobleach]

Rust also has great tooling. Clippy, Rust analyzer (the LSP). Developing Rust in NeoVim is just as fun as Go.

Other languages that do ok are OCaml, Elixir/Gleam, Typescript. Go and Rust just have what I consider a "cut above" the others when it comes to both tooling and standar language features.

[serial_dev]

Dart’s tooling is also good and basically the whole ecosystem use these tools provided by default.

[vbezhenar]

There's a spectrum. notepad.exe, vi, emacs/vim/notepad++, vscode, idea. Every new layer adds more features and adds more bloat. You can upgrade to the next layer by installing enough extensions (if editor allows it and those extensions exist). You can certainly turn your bare vim into vscode comparable editor with enough extensions. And you can certainly install enough extensions into vscode to make it comparable with idea.

An important thing is to find a personal sweet spot. For me, using Idea with hundred plugins is just not worth it. Spring plugin comes with thousands of features, but when I disable it, miss very few things, and the bloat is real: slow start, lots of new menu items and icons, new bugs.

I, personally, prefer to use editor on steroids like vscode, with full language-aware support. At the same time I'm using external terminal a lot, doing builds and stuff there. So IDE for me is an entire computer and vscode is part of this IDE.

[tsimionescu]

> notepad.exe, vi, emacs/vim/notepad++, vscode, idea

You forgot the natural root of this hierarchy: ed, the standard text editor.

https://www.gnu.org/fun/jokes/ed-msg.en.html

[The_Colonel]

> And you can certainly install enough extensions into vscode to make it comparable with idea.

No, you can't. Comparable plugins don't exist.

[bitzun]

Also the quality of vscode is strictly worse. I tried it a few years ago and syntax highlighting a basic python program using stock vscode would get stuck (highlighting the wrong characters in random colors) in nondeterministic ways. I tried it again recently and I still see syntax highlighting bugs. Vim does a better job.

[ramon156]

There are people out there who don't even use an LSP with autocompletion or type handling, just syntax highlights. There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon.

I do agree that some nvim setups are just IDE's in your shell, but it's also nice to have everything in one place. I don't like vsc's and Jetbrains's terminals at all, as it gets clunky too quick. To each their own though!

[tolciho]

Syntax highlights were probably the first thing I disabled in vim, though they kept adding features—"that's nice, but how does one turn it off?"—so I'm on vi now. Hella distracting to have bloatware spam you like a pachinko parlor, but some folks will want that whole three ring circus cruise ship with the bearded lady tour, I guess. Color support got itself compiled out of the terminal, to avoid the results of git randomly squeezing the backside of a unicorn. Unix here is the IDE, which is fine, as I'm mostly not a programmer (why programmers keep launching flaming turds into production despite all the increasingly fancy tools is a somewhat entertaining question) and 35,000 lines of code is about the largest thing I deal with (vi, or a custom branch thereof). Plus some tools that I wrote that do exactly what I want them to. Multiple cores pegged because some AI nonesense is busy shoving crayons up its nose? No, thank you!

[freedomben]

I don't know if you are trolling or not, but if not, you are an interesting person (In a good way) :-)

I too prefer a much more minimal approach to my text editor. Then what most IDEs provide, but syntax highlighting is luxurious and a must-have for me. In general, I really love colors, especially the simple colors of the terminal. Color can be distracting of course, but it is a phenomenal way to quickly differentiate between related and unrelated parts of the code.

[bionsystem]

> why programmers keep launching flaming turds into production despite all the increasingly fancy tools is a somewhat entertaining question

haha I love the tone and I feel you, the state of software (and computing in general) keeps surprising me (in a bad way) as years go by. It feels like it's only getting worse. We can talk about their salaries too !

[xyproto]

You probably do this already, but setting NO_COLOR=1 to disable colors and syntax highlighting is supported by an increasingly wide range of applications.

[wiseowise]

> as I'm mostly not a programmer

What’s your type of job?

[BrouteMinou]

Thank you sharing your invaluable knowledge with such a precise and accurate language. It demonstrates clearly your deep understanding of the subject.

[soraminazuki]

LSPs visually warns you the instant you forget a semicolon, so that error will only happen when you don't use LSPs.

[sureglymop]

The best programmer I know very often codes in a simple notepad like text editor with no syntax highlighting or any kind of other help. Purely plain text.

He does this mainly when trying to show/explain something to someone in code and when initially drafting something. Not for full blown projects.

I still find it interesting though, because I personally don't nearly have good enough memory to even do that. I have to look things up constantly and rely on auto completion.

[mnsc]

I have normal memory but my interpretation of the worst programmer I've worked with is that he had extraordinary memory and used that to write extremely tangled code but due to remembering every call site and randomly named function he thought the code base was flawless. And the expectation was that efter he explained a piece of code once then I too should have committed that to memory and then be able to recall it days later when it unexpectedly mattered when explaining a new piece of code. Failing to do that would lead to a "sigh, I'll explain it from scratch again". I don't really remember but I think he used intellij, but like a tabbed text editor. Always ctrl-shift-f "startoffunctionname".

[Carrok]

> There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon.

I never want to waste a single brain cycle on a missing semicolon. That is what the editor (or autocomplete or AI or whatever) should be doing for me.

[robenkleene]

I used to think like this too, but I now categorize this as "making easy things easier" and I try to focus only on things that "make hard things easier". Now the main thing I value is flexibility, and that's mainly achieved by mainly spending my time in a programmable environment (the shell), and a CLI editor like Vim fits the most smoothly into this approach.

To give an example, let's say you want to make pull requests for an API change across several interdependent repos (e.g., an API change in a framework). So you want to you want to do a find and replace in each repo, then push the changes to a branch, and create a pull request for each one. This can be achieved entirely from the command line, making it really easy to repeat across all the repos that need to be updated.

(With all the above said, I do use most LSP features, like live error checking and autocomplete, but if I were forced to choose, I would give that up before I give up the flexibility of a programmable environment.)

[lolinder]

Using a powerful IDE does not preclude dropping into the command line for that kind of repetitive, scriptable work, and many of us do use both.

[wiseowise]

I’m curious to see how you’ll automate this in e.g. IntelliJ, that doesn’t allow you to open multiple projects side by side. No, opening multiple instances of IntelliJ is not the answer.

[lolinder]

Open terminal, run the script in the terminal? You don't have to load the IDE to write to files just because you do your manual work in the IDE.

[mekoka]

You think you waste brain cycles on semicolons? Do touch typists make a conscious effort to "remember" where all the keys are? When you read, do you go letter by letter to make sense of words and sentences?

Your brain is an incredibly efficient tool. You should trust it more.

[tsimionescu]

Brain cycles are still being used even if you're not conscious of them. So yes, some part of your has to spend cycles to remember to type that semicolon, and to even remember where the semicolon is on the keyboard, and in fact to remember how strong a signal has to be sent to the finger muscles to move the pinky to the right location and press the key.

In principle, this effort should even be measurable in calories (though it may be hard to distinguish from the noise of everything else you're thinking).

[mekoka]

I don't think you got my point.

Perhaps I should have originally been clearer, but I have no clue what these "brain cycles" that keep being mentioned are. If it's some kind of CPU analogy, brains and CPUs are nowhere near analogous in how they work. The brain is an extremely complex system, whose mechanisms we're far from understanding fully and whose activities are mostly unconscious and subconscious processes.

In the context of our discussion, energy expenditure is not really the relevant feature. The more useful "index" would be the "perceived (i.e. conscious) cognitive workload". One is addressed with caloric intake, the other has more explicit psychological ramifications.

It may have been presumptuous of me, but cognitive workload is what I thought GP really meant by "brain cycle" and that's what I was addressing.

The point I was trying to convey is that the brain is very good at moving chunks of work away from conscious processes to subconscious ones (i.e. away from perceived load) through various optimizations. Usually, exposing the brain to deliberate and repetitive tasks will tend to develop certain tacit skills (subconscious shortcuts).

Another subtler point, was that an easy mistake when evaluating how much cognitive work a tacit skill actually demands, is to appreciate it from the perspective of someone who lacks said skill.

[xigoi]

Ithe computer can reliably tell when you forgot a semicolon, why does the semicolon need to be there in the first place?

[Kwpolska]

You don't need a full-blown IDE to write HTML. Maybe for Python. But for languages like Java, you're leaving a lot of productivity and error prevention on the table.

[gf000]

Or different interpretation: languages that don't have IDEs with the feature set and productivity of Java IDEs are leaving a lot on the table.

[Sins_621]

I agree I think a lot of people do tend to go overboard with the plugins they add to Neovim. I only use a hand-full of plugins myself; Telescope for fuzzy finding, LSP for navigation and Rainbow-delimiters. I've found attempting to add anything "un-neovim-like" such as tabs or a debugger to be more of a hassle and jankier than just using something better suited to that task.

I actually think the best way to learn Neovim is to build your own configuration with as little plugins as necessary for you to get the job done because it'll force you to learn the Neovim way of doing things. For example instead of relying on tabs I learnt to use the Mark system and it was a great addition to my workflow.

[rat87]

The I stands for Integrated. Although technically I think the big 3 Java IDEs are written as a pile of plugins largely to support multiple languages. But they do tend to feel more "integrated"/look more cohesive. I guess the point is that if you feel like opening a text file in something it's a text editor. If you don't it might be an idea. I do try to open up individual text files outside of a project in pycharm sometimes but usually it feels weird. Maybe that's why they added scratch files. Somehow shift+shift new scratch file json and copy/pasting feels easier then making a new file outside your project with the IDE

[lkramer]

I use Vim (recently switched to Neovim on my work laptop) as my daily driver with a minimum set of plugins. My primary language right now is Go, but used to be C++. It works just fine for my purpose. I have tried using IDEs in the past, most recently vscode when I was trying to learn Rust, I always end up going back to Vim, I find it more a more enjoyable and streamlined experience. For IDEs it's usually a struggle getting everything to work for me, and if there is a new version it just ends up breaking everything. I'm sure it's just a matter of what I'm used to. However I learned JAVA at university and it's the one language I have never managed to come to terms with using vim. At university I used Netbeans and I think that remains my one positive experience with IDEs. I really liked how that worked (or maybe I just hadn't been conditioned that much at that point). Java seems to be designed around the idea that you should user an IDE though. Sooo Verbose, and so many frameworks...

[o11c]

The full statement is "You don't need a full-blown IDE, just use (vim or whatever), unless you are writing in Java". Among mainstream languages, Java is uniquely hostile to being written by humans.

The statement is usually shortened under the assumption that nobody is writing Java by choice, and if you're writing it for work you're forced to use (Employer-provided development tool).

There are other languages that are hard to use without an IDE, but they always are relatively obscure ones and/or blatantly integrate the language itself tightly into the IDE, like Smalltalk or Scratch.

Most languages, it's feasible to write with nothing more than a regex-based keyword detector and symbol tagger. LSPs are overrated, other than the fact that they're a narrow waist for supporting multiple languages in multiple editors.

[singpolyma3]

As someone who writes a lot of java (mostly for android) without any plugins I'm curious what about Java you think requires them?

[o11c]

`System.out.println` is ridiculous, and you're likely to use it many times unlike `public static void main`. Well, since there are only 2 of these I suppose you can simplify this to it's not hard to customize your editor to expand `sout` or something to that.

Java culture promotes long class names and method names, which are often neither unambiguous by prefix nor by initials, which are the 2 basic autocomplete styles (though really, I shouldn't allow the pro-Java argument to consider autocomplete at all, even a stupidly basic one).

Java culture (and to some extent the language itself, due to package-private) expects separation of classes within a project into multiple/nested packages, but package names are expected to be very long and there are no relative imports. And classes from third-party packages will also have horribly long names. New-file templates can help a little if you're willing to suppress "unused import" warnings.

The lack of support for "free functions" (outside a class) adds a ton of verbosity, if you can't fake them via dummy interfaces. Meanwhile, the fact that `this` is implicit makes the question of "what identifiers are in scope" almost as complicated as C++.

But yes, if you're paying attention, Java-the-language can be made somewhat nicer if you ignore Java-the-style (notably, many developers of Java itself are famous for doing this internally). But then you basically give up on the library ecosystem, which is the only reason to write Java in the first place. You can't even add interfaces retroactively!

Yes, I know they say "speed of programming isn't limited by how fast you can type", and it's usually true. But Java proves it can be bad enough to drop your cache.

[The_Colonel]

> `System.out.println` is ridiculous, and you're likely to use it many times

No, you don't use it often.

You can use it as a poor man's debugging tool, but Java actually has very nice debuggers. You can use it as poor man's logging, but then you have pretty good logging frameworks. Or you can use it as application output, but then you probably want to abstract specific output stream away from most of your business logic code and use interface.

[be_erik]

Java’s debug tools are first class and even this stubborn vim user knows to hand over the keys to Idea anytime I have to do anything in Java.

With that said I’m still a sout, puts, Printf, cout << developer.

[gf000]

So in that highly configurable and scriptable environment you can't create a macro like sout that expands to System.out.println, really?

Also, if it can't even import symbols automatically, then it sounds like a tool problem. Java is like one of the simplest languages, it has no fancy features, has sane imports, ultra-stable tooling, etc.

The point of an IDE is to improve productivity. And I think you just haven't seen someone who knows the ins and outs of an IDE fly while writing Java there.

[o11c]

My point is that "highly configurable and scriptable environment" is a much higher floor than other languages have. You don't need that to be productive in most languages; there are people who write serious code in nano or even notepad!

[gf000]

And what objective metric is there that prevents it from working in java? Because there are, in fact, people that write java in notepad, probably much more than those who write rust and go and swift there, combined.

[imron]

My .exrc file is about 10 lines long and has no plugins.

Combined with ctags and a terminal it’s all I need for the languages I’m familiar with (c, c++, rust, python and several others)

[SvenL]

I always wonder, how do you debug which such a setup?

[imron]

Gdb, lldb or pdb in the terminal.

It took a bit of getting used to at first, but then it just becomes normal.

[theonething]

I like working in terminals. An IDE will never run in the terminal. Vim with the plugins I like run in my terminal.

[pjmlp]

Showing the age, Borland IDEs for MS-DOS, as one data point among many other ones.

In fact, the whole TUI craziness of IT world fashion is getting back to what used to be daily business in the 1980's and early 1990's.

[lolinder]

Sincere question from someone who doesn't understand this: why do you like working in terminals?

[gloosx]

It's faster. There are all kinds of vim modes and shortcuts in IDEs, but only in terminal you can turn off your mouse completely and just use the keyboard. It's also faster than any GUI program in terms of responsiveness, everything happens in an instant, and there is not a single animation, even when working with a 1GiB log-file. Vim is also a very robust tiling manager, convenient splits and navigation between windows, terminals and editing buffers out of the box.

[bionsystem]

Not the op but I like it too and here is why :

- I like awk grep sed find and many more... and piping things together

- I like the low latency of vim and love walking through code with just a few movers

- I like the ubiquity of using the same tools on any machine, local or remote (including windows now that it has wsl) and bash

All of this even more so than "no mouse setup" or anything, I don't mind using the mouse sometimes.

[camgunz]

I find that terminal apps are a lot more respectful of my machine's resources and whatever workflow I want to build. I can make them work like I want to. GUI apps make me work the way they want to, which as an incorrigible non-conformist is a real fly in the ointment.

[maxbond]

A programming language is a good abstraction for interacting with the computer. It's a metaphor for how a computer works. Graphical tools usually provide metaphors for how a certain set of tasks are done. The terminal is a REPL for a programming language designed for this purpose.

Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another.

For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader).

If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.)

And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files.

(Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)

[lolinder]

I guess I should have been more specific: I get all that about CLIs, but that doesn't really explain wanting your editor to run in the terminal. I usually have an IDE open alongside a bunch of terminal windows. What am I losing by not also running my editor in a terminal?

[maxbond]

You're probably not losing out on anything if that's comfortable for you. The primary advantage to me is avoiding context switching between a GUI and terminal mental model. But that probably just doesn't bother you.

[mardifoufs]

I also need to configure which "plugins" I want whenever I install regular Visual Studio. In fact you can't really even start using it before that initial setup window. The time it takes to install and configure a plugin on vscode, for example, is basically 0 for most languages and platforms.

[singpolyma3]

Thu people saying the former are different people than the ones installing all dhise plugins. I just run without plugins mostly

[robenkleene]

Today I generally think of an IDE supporting one language (or a few complementary languages) without any configuration, whereas a text editor usually requires configuration to get the same features. Although it's true the features are almost identical now. Though IDEs typically still offer some special sauce features, usually things that still don't fit cleanly into LSP and DAP (language server and debugger protocols respectively) models. On the flip side, text editors typically (lightly) support more file formats out of the box, and scale better, e.g., equally comfortable editing a single file or an entire project. TLDR: the trade off is between flexibility (text editor) or specificity (IDE).

[TacticalCoder]

> I wonder at which point do we call it IDE instead of text editor

The most hilarious to me is when people refer to Emacs as a "text editor". I'm not talking about the fact that Emacs shall happily display pictures (inlined in a file like in org-mode for example or in their own window), open binary files, open PDF files, manipulate files over SSH (Tramp), etc.

Heck, as a statement some made Emacs run as PID 1.

But many seem to honestly think Emacs is "notepad with bad shortcuts".