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.
Only languages with negligible market share don't have 3 decades of legacy warts.
Nonetheless, I wouldn't write either of them without a proper IDE.
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.
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.
Requiring building app before having a preview and then waiting between 10 seconds to a minute on every change is what you call joy?
The only language that comes to mind fitting this description is 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.
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.
You forgot the natural root of this hierarchy: ed, the standard text editor.
No, you can't. Comparable plugins don't exist.
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!
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.
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 !
What’s your type of job?
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.
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.
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.)
Your brain is an incredibly efficient tool. You should trust it more.
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).
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.
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.
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.
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.
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.
With that said I’m still a sout, puts, Printf, cout << developer.
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.
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)
It took a bit of getting used to at first, but then it just becomes normal.
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.
- 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.
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.)
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".