What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.

It could be - but in the majority of cases it isn't - and you will need to fall back to CLI and UNIX abstraction layers when the IDE breaks - because that's the way it's been done since forever and if you want to work with existing (and probably future) tooling and be able to solve the problems when they happen in the layer above you will need to learn the interface used to expose all the functionality to the tools under the hood.

> It could be - but in the majority of cases it isn't

I don't think that's really true, at least for the Java ecosystem which is implicated here. Eclipse does not call out to command line tools for most things, as far as I've seen

> "What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler?"

Build and CI systems don't go through a GUI IDE, making it required for developers to understand the CLI anyway.

As an example, Maven support in Eclipse and IntelliJ don't call the Maven command line application, they operate entirely within the IDE.

> What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler

It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.

The CLI is more explicit than a GUI. In a GUI, compiling / running / testing your code is an afterthought that happens at the click of a button.

In the CLI, you have to be explicit about what actions are taking place. You have to physically type in what command you want to run and the different arguments to it.

The convenience of a GUI is fantastic, but the abstraction makes it a very bad learning tool. Being able to open up a terminal and fix the inevitable git / build / configuration errors is a very valuable skill that developers should have.

I don't see the distinction. I started my career using command line tools and am completely comfortable with them. Yet for more recent projects I stay within the IDE (usually Visual Studio).

It doesn't matter whether I tick a checkbox for compiler warnings or add that option to the command line. The only difference is the IDE makes options easier to discover.

It's the same for Git. A decent GUI gives you a much better visual picture of the state of your working copy.