A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers because they didn't know any tooling. They couldn't compile, run, test, or source control their code if the professor didn't set it up for them.
Yes, tools change, but the knowledge from one tool is almost always transferable. Once you're comfortable on the CLI and understand the concept that Java source is compiled to bytecode and then run on a VM, it's easy to switch to a new compiler.
If you only want to know the absolute bare minimum, go to a boot camp. People go to college to learn, and being comfortable with tools is an essential part of being a developer that students need to learn.
This is no fluke! If you don’t know how a classloader works with the Java classpath, how to set various JVM flags for operating the JVM, etc., then I’d argue that you’re an amateur, and I wouldn’t trust you to write correct code in a production setting. It’s critical knowledge to know how your code runs, and if you don’t know that, then stay away from production systems. If the goal of these courses is to teach students enough about Java to use it in a professional setting, then knowing how classfiles are produced, bundled, distributed, loaded, and executed by a JVM is critical knowledge.
More succinctly, if you don’t know how your code makes it to a production server and gets executed, you’re not ready to work on it.
(And if the goal isn't to teach students how to use Java in a professional setting, then why are they learning it at all? Use a teaching language so students can focus on the concepts instead of Java's idiosyncracies.)
But I don't think it is such a key to anything. It is sort of stuff that is easy to learn when you need it, easy to forget and not useful most of time. It makes sense to read when you done learning other things, but not for beginners.
The problem is the IDE makes it so easy to never have to look under the hood, to the point when people take a peek the get overwhelmed and quickly return to the comfort of the IDE.
However, in real world of production environments there will be no IDE holding your hand and as such you can't get away without a good understanding of the engine under the hood.
In real world, you always use tools and in real java world there is always ide or application server or something.
Plus downloading the actual Java SDK was confusing, the versioning, it not being free anymore...
IDEs change more frequently.
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).
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
Build and CI systems don't go through a GUI IDE, making it required for developers to understand the CLI anyway.
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.
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.
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.
I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.
Edit - I should mention that my last sentence was the perspective of 18 year old me. I was 18, but in my defence I was 18. :)
being a useless developer doesn't make it not computer science. not all of computer science is software development.
Learning a programming language has nothing to do with how it's seen by a computer. That's a different class (a class on compilers, maybe). You can even turn Java into Javascript if you want to[1]. The fact that the compilation/transpilation flow here is Java -> Java Bytecode -> JS is meaningless in the context of learning Java.
Learning the syntax of a progaming language might not have much to do with how it's seen by a computer but it's important if you want to learn how to use a language properly. If you don't know how Java(or any language) works fundamentally, the code you write may work, but it'll likely be more inefficient both in terms of program and programmer speed.
Debugging sessions will be more frustrating and take longer and generally the quality of the programs you write will be lower compared to programs written with a language's quirks and peculiarities taken into account. Which you learn by understanding how a language works.
I'm not saying they should be able to write a Java compiler or interpreter, but they should have a decent idea how they work at least fundamentally.
It's harder to learn this when it all happens at the push of a button and you never learn to appreciate that button because you've never had to do it yourself and if something goes wrong with that button for some reason, you won't understand how to fix it or work around it.
Knowing Java runs in a VM very much affects how you have to code. Sure, when you are learning in a 100/200 level class it doesn't, but by the time you graduate if you don't understand the implications, that is bad. Why not make a very simple change early on that gives context for students later on? We shouldn't be teaching students that Java runs in a virtual machine in a 200/300 level class, by that time we should have moved on to why that matters.
Forcing students to continually use java/javac will make them start learning the concepts on how a computer actually processes their program. It makes them think a bit more about it and the concepts are not foreign when they learn it in a full class. The IDE just turns the whole process into a single button with little context.
The author, Leonora Tindall, is a woman.
The only thing you need an ide for is autocomplete and refactoring, and in a small project like you have in school, it’s simpler to use a text editor imho and you can fully understand your project that way too
Eh, javac is the reference implementation and the language specification makes several references to it, it's also by far the most widely used. It's also good to understand what goes on behind the scenes in your IDE because the IDE is even more removed from the language than the compiler. C++ is somewhat different because it does not have a reference implementation and has a somewhat more diverse set of implementations. Though I think it's still very useful know your way around the gcc or clang command line.
> These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
Imports and naming are not implementation details... they are defined in the specification.
> These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
In Java, these are language details. You cannot write Java without following them.
I also think that Java is perhaps the worst possible choice for that.
It's a language created with the "build once run anyway" mentality that tries to abstract away the system, it's the poster child of languages married to an IDE, and verbose to the point that forcing people to write java code without autocompletion features probably violates the Geneva convention.
At this point in time if you want your students to learn about tooling it would be more useful to teach them to use chrome's JavaScript console than to teach them to use a Java compiler through the command line.
I'm happy to use just emacs. The naming conventions make it easy enough to remember. I've never been a fan of heavy IDEs. Maybe that is just me as a solo developer/entrepreneur, but I don't think that I am the only one.
Once you decouple yourself from the IDE and all of the bloated enterprizey (ahem spring) frameworks, it is actually pleasant to work with. Most of that stuff is superfluous when you have a command of the environment.
In my personal case, knowing about classpaths the hard way was my only path to salvation. Otherwise I was blindly tweaking IDEs project configs without any idea what was happening.
There's more typing with a text editor and javac, but it's much simpler to understand IMHO.
All of this must be understood in the context of first year programming. For my class, there were no libraries that one needed, and at most 10 or so java files to compile. The classpath would never need to be more than the working directory.
Using the tools directly serves to re-enforce all these concepts.
They can get to know other tools for that same language like in your Borland example, sure. But if you didn't know the compiler existed, you would be in trouble. And in C you will also want to understand the preprocessor and linker.
Such a misguided article. The Java language has (quite literally) nothing to do with `javac`. In fact, there's a lot of other compilers out there. Taking a Java class should not focus on the intricacies and weirdness of Java compiler command line interfaces. It seems pretty amateurish to argue in favor of it. Case in point: back in high school, I learned C++ using a Borland compiler (and I haven't touched `bcc` in the 15 years since then, even though I've written plenty of C++ in the meantime).
> ... imports and file naming requirements.
These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
> And of course, mathematics is the foundation of computer science.
Stuff like this can be misleading and even though not completely wrong (discrete math, logic, metalogic, mathematical logic are sorta' kinda' similar), it's just wrong enough[1] to lead people astray.
[1] https://www.scott-a-s.com/cs-is-not-math/