Language agnostic development may be quite viable within a year or so.
I doubt that very much, GPT4 (to my knowledge still the best LLM) is far from being there. As (my) initial hype is overcome, I have basically stopped using it because I have to "help" it too much (and it got really worse over time...) so that I spent more time to get any usable results from it, instead of just writing the goddamn code myself. There has to be a very large step in progress, that this is anywhere feasible (maybe that's true for some "boilerplate" react UI code though). You have to have in mind, that you should still review all the code which takes a good chunk of the time (especially if it's full with issues as it is with LLMs). Often I go over it and think yes, this is ok, and then I check it out in more detail and find a lot of issues that cost me more time compared to writing the code myself in the first place.
I have actually fed GPT4 a lot of natural language instructions to write code, and it was kind of a disaster, I have to try that again with more code instructions, as I think it's better to just provide an LLM the code directly, if it will really get smart enough it will understand the intentions of the code without comments (as it has seen a lot of code).
Context size is also a bigger issue, the LLM just doesn't have as much overview over the code and the relevant details (I need to try out the 32k GPT4 model though and feed it more code of the architecture, this may help, but is obviously a lot of work...)
Same for humans, if your code is really too complex, you can likely simplify it, such that humans can read it without comments.
If not, it falls for me in the first category I've listed (complex math or similar). And then of course comments make sense for a complex piece of code that may need more context.
I would only add comments otherwise for edgecases and ideas (e.g. TODO).
For the rest a good API doc (javadoc, rustdoc etc.) is more than enough (if it's clear what a function should do and the function is written in a modular way, it should be easy to read the code IMHO.
Really if you need comments, think about the code first, is it the simplest approach? Can I make it more readable? I feel like I have written a lot of "unreadable" (or too complex) code in my junior years...
What otherwise makes sense for me is a high level description of the architecture.
I think even the second comment is not that helpful.
Just use (boolean) variables that phrase what your comment would explain, often more concise and better to read IMO. Also if the logic is more complex compose multiple named (boolean) variables. I think comments seldom make any sense at all (function doc is a one of the rare cases, mostly for the user of the library in the IDE).
Just write your code, so that you (almost) don't need comments (i.e. simple to read). The problems with (most) comments won't be solved by AI.
(in-code) comments only make sense for me in roughly these scenarios:
The problems with comments are explained well IMHO here: https://www.youtube.com/watch?v=Bf7vDBBOBUA
It really depends. Maybe developing something like a game will require (almost) no CLI.
But do a little bit more server stuff, dev-ops, and you can literally not even do the job without cli.
Though in general, CLI is often better for the task, it often can easily be automated (via scripts etc.), which seems to be relevant for a lot of tasks programmers do...
Hmm yeah it probably helps to be able to program functionally (it's basically lambda calculus with lazy sets and a little bit of syntax sugar). NixOS has a little bit of a steeper learning curve. When understanding Nix itself and having a little bit dived into the the nixpkgs repo you'll quickly get a grip for it (and understand some of the IMHO quirky design decisions).
But then I feel it's only going to get better, as the system can be perfectly configured to your liking and it stays like that across different machines etc. I think the initial investment has paid off for me so far. It's really hackable and you can quickly try ideas without having to fear to break your system. Also something like nix flakes for good reproducible dependency management across different OS is really nice (at least if not much if any GUI is involved, then the different worlds (impure vs pure) sometimes clash together).
You might want to checkout NixOS (or home-manager if you don't want a cold deep dive into a rabbit-hole).
Depends on what you mean exactly with "file format".
If declarative functional programming falls under that, I think something like Nickel, the already mentioned Dhall or Nix. Though Nix more so for packaging and some kind of system management (NixOS?), it's not easily embeddable into a runtime (your app?). Nickel or Dhall is better for that, as they are built from ground up with that in mind, Nickel is maybe the successor of Nix as it is inspired by Dhall and Nix (one goal is to use Nickel as frontend).
The reason why I recommend a simple declarative language, is that they are IMHO much better composable as it lets the user hide boilerplate via functions. I almost always feel limited by static configuration formats like yaml, json etc..
Is this a hard error? Like it doesn't compile at all?
Isn't there something like #[allow(unused)] in Rust you can put over the declaration?
Is it good technically though? Or is it just really popular because it's so well maintained and extensible?
I think the main reason vscode is so popular is, because there aren't really good native alternatives (e.g. I wouldn't compare e.g. vim because it's kind of a different target audience).
So maybe something like zed or so will take the reign of this class of editors, but we'll see, I just hope it's not yet another electron or DOM based editor, DOM is bad enough in the web already...
So cancer + a different form of cancer = ...?
I really don't get why you want an editor to be based on DOM, it feels just like sluggish ... cancer...
I actually think java is more cumbersome to write, Rust is definitely higher cognitive load though (get the typing right, fight the borrow-checker etc.).
With cumbersome I mean, that the language limits yourself with a relatively bad type system (compared to Rusts) and often results in a lot of boilerplate and IMHO generally promotes the wrong patterns (I think https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition brings this on point in a comical way). But I'm biased, I much prefer functional programming vs object oriented programming...