[bradlys]

Intro classes don’t need to overburden the student. The biggest hurdle for students is thinking like a computer. You start introducing all these extra things to just get going and it becomes even more difficult.

Explaining to students what public static void main means is pretty annoying and seeing cryptic syntax littered everywhere does not help students when they’re first learning.

Dynamic languages make much more sense to beginners because the idea of what a variable represents is more abstract to them than tangible to you. To them, they don’t see the value of types because they’re not going to be building large programs where that is going to matter. They know what their functions return and take in, because they probably only have one or two. Performance and compiling is also not as much of a concern, etc...

[flowerlad]

> Explaining to students what public static void main means is pretty annoying and seeing cryptic syntax littered everywhere does not help students when they’re first learning.

C# has solved that with "top level statements" [1]. If Java added that then problem solved, right? It's a simple addition.

[1] https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

[dvdkon]

C# would be a better choice. In addition to top-level statements, the standard API seems much less "dogmatically" OOP. Reading a file is just one static method away. Unfortunately, it's still not possible to have top-level functions, right?

[kaba0]

But C# on the other hand is a very very complex language, with almost double the keywords compared to Java.

[dvdkon]

Yes, but I think the learning curve matters more, especially for students who are going to be mostly writing code, not reading existing projects.

[kaba0]

I agree with you on the overburden part, but not on the dynamic lang part. My very minimal experience is that the hardest thing to get right as a beginner (or even as an experienced developer) is to be able to follow the flow of your code (Maybe introductory courses should employ the debugger?), and the exact state it has at a given point, eg. at an exception. Restricting the valid states imo helps understanding. As well as not having to debug at all at first, but the compiler notifying what is wrong immediately.

[hurflmurfl]

I think that you're right in that it's hard to compose all those parts of your program together without accidentally mistaking a `Query` for a `string`, or god knows what. I'm helping a friend learn web development, and most of the issues they get stuck for long time at are solved by making sure that functions you are calling are returning what you think they are.

On the other hand, I feel that most of the lessons I've learnt that have really stuck are the ones where I first do a thing wrong, and then find how to do it right. In a similar fashion, letting the student create a steaming pile of ... and then giving them a solution to their troubles in a later course feels like a good idea.

I personally have come a full circle: starting with things like Pascal and C++, then going to C# and finding type inference interesting, then getting a HUGE boost to my knowledge and skills when I found Python and JS. A few years later, my personal preference is having static type checking, and Typescript does that pretty well, in my opinion. However, every time I remember how much I managed to learn and understand about programming when I switched to Python, I think that if I had to teach someone, I'd pick something expressive, intuitive and who cares about types when you really want to maximize exposure.