It could be my chauvinism speaking. I'll admit to having some. My CS program taught us three relatively small programming languages (Scheme first, followed by C, and then MIPS assembly) in the first year before introducing OOP in the second year. So we ended up getting exposure to a variety of programming paradigms and environments, and came away with a lot of tools in our belt, and a fairly deep understanding of programming language theory and paradigms. And I did eventually find myself settled in a Java shop. When I did, I found that within only a couple months I had already developed a deeper understanding of the language than colleagues who had spent their entire careers working in it. And I believe a lot of that is because I had enough background knowledge to distinguish between, "This is how programming is done," and, "This is how programming is done in Java."

And before someone points out that, actually-technically, Java is always pass by value, I will pre-retort that reference-as-value isn't an argument we should ever be having about an intro programming language.

Either teach a systems language with unambiguous pointers, or teach something that abstracts consistently.

I understand why (now), but at the time, it just added unnecessary cognitive load on top of already learning hardware models.

C and Pascal require fewer exceptions, despite a larger base knowledge requirement.

C++ is ok. Students can use a very simple subset of C++, they don't have to use the more advanced parts of it.

C is even better.

Go is fine, too.

Typescript is a good enough choice.

Thanks to C and C++ I did understand the most important bases of programming, how a program runs, how hardware works and the most important algorithms and data structures.

I think it's important to learn something that doesn't do too many abstraction but it isn't too low level like the assembly language.

You need to understand

* access modifiers (public/private)

* classes

* static methods

* void return values

* the main() function

* modules (System.out.println)

Just to understand a basic "hello world". It's too much for first-time programmers.

    class Test {
        public static void main(String[] args) {
            System.out.println("Hello world");
        }
    }

    javac Test.java
    java Test

* Class is in file with the same name ¯\_(ツ)_/¯ and contains functions (maybe it'll help me later in organizing code?).

* Command line arguments (not strictly necessary concept but not too problematic either)

* Types - why is there String[] in the definition? (A must have in a statically typed language anyway)

* void - the function doesn't return anything (OK)

* public (not OK, some magic here)

* static (not OK, some magic here)

* Compilation vs. run step (a must have in a compiled language)

So IMHO there are just two concepts that could be thrown away. Or three, if you accessed CLI args from a library. But the meaning of public and static will come naturally when the students will learn about OOP.

Sounds like excellent training for a long and successful career in enterprise Java.

  > * access modifiers (public/private)

To be super thorough, you would also have to understand:

- semicolons (and the related issue of newlines being semantically equivalent to normal spaces)

- naming conventions (to explain why it's not "System.Out.Println" and "Main")

If someone applying for an architecture degree or engineering degree is required to have basic drawing skills and basic math knowledge, why we shouldn't assume the same for CS?

If I was a teacher and I'm going to teach someone what a linked list is, or what a binary tree is, I can of course use natural language and drawing, I can use abstract algebraic concepts.

But the student should be also able to construct said structures and observe how they work. The same for any other concept.