[chii]

> If you’re teaching Java you should be teaching Maven

no you shouldn't, because the premise is invalid. A university student shouldn't be "learning java". They should be learning programming, and theory of computing (and algorithms etc), and perhaps use java as the language. None of this requires maven, build tools or any tool chains beyond some unit testing framework (and GUI framework if displays are necessary).

Don't teach "industry standard tools" to a uni student learning CS.

I would not expect a new graduate to know maven, or know the intricacies of the spring framework. That's something to be learnt on the job. I expect them to be capable enough to learn this on the job - given that they're well versed in the theoretical aspect of computer science. It's easy to explain maven's core by telling them that it's a directed graph of dependencies.

A student that just learns the "industry standard tooling" should need a bootcamp, not uni degree.

[closeparen]

CS students should be learning those fundamentals by programming, and so they should be taught enough tooling to program without tripping over themselves all the time. Programming without a build system, a version control system, or a reasonably intelligent editor is unnecessarily difficult and gets in the way of the concepts being taught.

[chii]

> Programming without a build system, a version control system, or a reasonably intelligent editor is unnecessarily difficult and gets in the way of the concepts being taught.

Programming with a build system, with a vcs and/or an editor with intellisense features will unnecessarily burden the student with learning these extra things. vanilla java, taught using a pure text editor (like pico, or notepad++, that has a simplistic syntax highlighting), and make sure the students type out their own imports, etc, is going to teach them more basics.

Until the day you need to build actual working software to ship to people, there's no need for a build system, and until they need to work in groups, there's no need for VCS. And until they start writing something _very_ complex, like a full game using many libraries, they don't need intellisense.

Most CS exercises fit in one class. And when it comes time to design something reasonably complex, the student would've learnt all the fundamentals (like 6 months in), and can move to using an IDE with little issue. And then when group projects come, the students can learn VCS as it makes group work simpler. But till then, showering the first year student with these tooling is just noise.

[closeparen]

Compile errors due to misspelling and "what was that function called again?" expeditions are distractions. My department did us a great disservice by never even hinting to students (at any level) that tooling can make them go away. It was almost painful, working on group projects, to see my classmates struggling so hard just to move around the code. Being unable to seamlessly work your editor and navigate your codebase is just as crippling as hunt-and-peck typing. Is it worth a lecture? No. But a mention? Absolutely.

VCS is essential in a solo project of any real complexity because you will reach intermediate milestones, go off on tangents that don't pan out, and then desperately wish you had a way to get back to the working state you had hours previously. A true VCS with branching and merging is technically overpowered, since you could just make copies of the source for each "commit," but you may as well just use Git.

Build system is not about shipping to people, it's about running what you just wrote on your own machine when it's bigger than one unit of compilation (C file, Java class, whatever). You don't need anything fancy, can just be Make or a shell script, but building and running the whole project should take no more than a few keystrokes. Kids should be fumbling with GCC flags for maybe one assignment, not 4 years.

On the very first day of programming, all you need is a REPL. But once students are doing programming projects of nontrivial size, they should be invited to try incorporating the tools that make them manageable.

[therealdrag0]

It’s also a pretty decent representation of stuff they will be expected to learn and deal with on the job. I can’t imagine programming without dependency/build tools, and yet I also often struggle with them. It seems dishonest and impractical to me to only focus on core concepts. Students should also be exposed to real life!

[na85]

>A university student shouldn't be "learning java". They should be learning programming, and theory of computing (and algorithms etc), and perhaps use java as the language.

What is the real world difference between "learning java" and "learning programming, theory of computing (and algorithms etc), using java as the language"?

Surely to learn all that shit (using java as the language) you at some point have to, you know, learn java?

[Izkata]

Was about to reply to GP similarly, but after rereading it - I think they just expressed the sentiment badly. Note the single sentence they quoted in the reply - about teaching Maven.

Pretty sure they're reading "learn java" as "learn the language + the common build tools + more", instead of just the language, as we are.

Almost all beginners absolutely need to be taught the language first (so they have something concrete to mentally latch on to), not concepts and algorithms. However, Maven is not one of those things - either a GUI with a compile button or "javac" is sufficient at that level.

[NoraCodes]

> Don't teach "industry standard tools" to a uni student learning CS.

This is the critical point. By the time a curriculum is in place around one set of "industry standard" tools, new tools will have come out, in a lot of fields (see, for instance, `npm` and `yarn`.)

> They should be learning programming, and theory of computing (and algorithms etc), and perhaps use java as the language.

I would argue that using Java as the language for introductory CS courses is not a good idea. We have better, simpler languages to teach foundational functional (Racket, Scheme) and imperative (Python) languages.

There's nothing wrong with Java in general, but if your goal is teaching "programming, and theory of computing (and algorithms etc)", there's nothing that Java can do that Python can't that helps with that goal.

In fact, I'd give my optimal progression of languages as starting with Python for basic imperative and OO programming, or Racket for basic functional programming, then switching to the other one, and then looking at Kotlin (or Java if you really must) for advanced OO programming and C (or, in a few years, maybe Rust) for systems programming.