Hacker News Reader

> And to this day I find junior devs struggle with the same things unless they have a maven/gradle project all set up for them.

Personally I’m still shocked that learning the common build tools for whatever language is used for a CS course is not the standard. If you’re teaching Java you should be teaching Maven, if you’re teaching C++ you should be teaching CMake. Not to the “I can write my own plugins/macros level” necessarily but at least to “I can create a project that will build without my specific IDE or needing to recite compiler arcana”.

Nobody in their right mind works without these things, and while knowledge isn’t going to directly transfer from one to the next you should at least have enough to know where to look in the documentation for “how do I specify dependencies”, “how do I tell it where to find my source”, etc.

For a first year course where you aren’t pulling in the kitchen sink the IDE project format works well enough, but if you’re entering the workforce you should know damn well how to create a basic project in the standard tools of your language of choice.

> 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.

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.

> 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.

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.

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!

>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?

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.

> 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.

> ...if you’re teaching C++ you should be teaching CMake.

I've been programming very advanced C++ for close to 20 years now.

Never had any reason to use CMake.

Plain old make for when you just want to build something without expending effort and brain cells, or (nowadays) nix if you're putting together an industrial-strength build environment.

CMake is the worst of all worlds, and provides no benefit unless you really want to build Windows exe's with Microsoft's proprietary tooling. (And let's face it, Windows is a legacy dying platform here in 2020.)

Actually I agree for the Java world here. Thanks to the design of Java and many Java libraries you cannot write a little more complex Java code from your mind. Even importing all this nested OOP libraries is complicated without an IDE. For me Java is really a language which is impossible or too time consuming to master without a good IDE.

Working for many years in the python world professionally some people are still amazed that I'm essentially using more or less a normal text editor. IDE is optional for many languages but for some languages it's a strong requirement.

When I was teaching myself to code I started writing Java in Notepad. Not Notepad++, just Notepad.

And it was as painful as you'd expect, put me right off Java (most of my learning was in Python), and didn't really teach me much that I now use as a developer in a JVM shop.

I also was working with java professionally for many years, and I find it completely unbearable to write java without an IDE.

For other languages, e.g. go, which i currently like, I don't use an IDE because I don't feel like I need one.

In my opinion IDEs are often just a crutch for bad languages and I can understand the sentiment in the article, but yeah, java.

Java is special since the whole compile/link/run loop is relatively slow and there's no REPL. In Nodejs or python you are expected to just run your code. Any error like a bad import/require statement you can correct quickly and re-run. Maybe even add/remove print statements while at it. And it's not just dynamic languages! You can have the same experience in Haskell.

There is a REPL as of JDK 9: https://en.wikipedia.org/wiki/JShell

> and general concepts of writing software.

Especially if it is their first experience writing code. Until a student learns to tolerate the discomfort of "the machine isn't doing what I want for some inscrutable reason", it makes no sense to throw them into package-management errors.

> I still found dealing with matters of classpath and javac remarkably complicated.

I started my programming career writing C and C++ using the cli and a text editor.

Some years later I ended doing some Java and to me I found it quite easy as I could see similarities with things I had learned writing C and C++.

I could see the classpath and jar files where roughly equivalent to the concept of libraries and libpath found in the C and C++ linker (only much easier to use) and the javac was roughly equivalent to the gcc or g++ command line compilers.

> I'm all for folks learning these skills eventually, but in a first-year CS class I'd really rather students worry about the language and general concepts of writing software.

This is a big part of why I recommend that another language should be used to teach introductory level courses. Java has too much additional complexity. That complexity has benefits in production, but not for first-year undergrads.