Using an IDE does stunt learning though. Whether that’s a problem is up for debate. But relying on the run button, or auto completion does offload the need to remember how the cli fits together or learn library apis .
From personal experience and from the popularity of rstudio, jupyter etc. the evidence points in the other direction.
It’s because when you start out you just need to learn what code looks like, how does it run (do all the lines execute at once or sequentially), that you have these boxes that can hold values etc.
Given that form most of my projects, the run button is a convenient wrapper over “cargo run” or “cargo test — test-name”, or “python file.py” not super convinced of the argument.
Maybe in C/C++ where build systems are some kind of lovecraftian nightmare?
It's actually this language-specific packaging ghettos that exist precisely in order to hide the grotesque reality of how difficult it is to directly use third party code in these languages.
People making new languages should resist this trend. Do not implement another damn package manager. Think about the problem and make it easy for people to just use someone's tarball of code.
Some Makefile knowledge does not hurt much, but other than that it starts to become a nightmare.
Another big difference is the size of the standard library. One can hold on his brain all the information needed to program in C, but I would argue that for C++ or Java it would be too taxing and an IDE is almost a requirement, the alternative being consulting the documentation often.
From personal experience and from the popularity of rstudio, jupyter etc. the evidence points in the other direction.
It’s because when you start out you just need to learn what code looks like, how does it run (do all the lines execute at once or sequentially), that you have these boxes that can hold values etc.