The author is specifically talking about students. The emphasis at this stage plays a key role in whether they'll have that interest or not. Knowing is a prerequisite to developing interest.

I agree, but regardless of if they're exposed to a CLI, they will be exposed to tooling. Why is GUI tooling less likely to spark that interest?

GUI tooling almost entirely uses the command line layers under the hood, so it is strictly more complicated while hiding more of the real process - the worst of both worlds.

My point about Git is an example of this. Teaching Git is hard, partly because Git's command line UX is bad, but layering the complexity of, e.g., EGIT on top doesn't really remove most of that and makes it harder to teach (because expressing what to do in a GUI is strictly harder than communicating text commands, among other things).

EGit doesn't call the git command line application, it uses a Java implementation of git. Although I can agree it's debatable whether they have improved on the command line interface or not.

IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.

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.