Actually, the class you linked was an experimental class, and we ended up going with Python instead. (source: I was the head TA for that class)
Personally, I think we should be teaching static types and I pushed for Typescript, but it didn't happen.
As someone that teaches college students to program (not in a CS department) that statement is correct but doesn't provide the full picture. It's good to get rid of the extra syntax if and only if you don't need it - and that means you're intentionally limiting what you're teaching them.
Yes, that’s the point. It’s an introductory class, choices have to be made about what to teach when.
Another option would be to introduce Python types:
def square(x: int) -> int:
return x*x
At the moment the Python community seems pretty anti-static-types, and the core scientific libraries (numpy, matplotlib, pytorch) don't export type signatures. Language server / intellisense support for type inference also has a long way to go.
I would assume as types become used more a definitely typed type project will happen on pypi.
I think Java fits better as an introductory language — it is similarly popular as JS and python, and while I’m sure static typing can be picked up easily, I think fighting the compiler for a likely-correct program in the end is a better alternative than understanding why the program failed with this given input and not with another — so my not-backed-up-by-teaching opinion is that dynamic languages are not necessarily a great fit. It also features the basic OOP concepts, and modern java can showcase plenty of FP ones as well.
On the other hand, going lower level is similarly detrimental, I’ve taken a class where C was used, and that way you get cryptic runtime errors as well, while memory management is not that hard to pick up later on.
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...
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.
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...
In my experience (having TAed a CS1 course) I think it is better for introductory students to be able to figure out what they are doing wrong, rather than having a compiler point it out to them.
In the first class, we want to focus on computational thinking and being able to then express their ideas into programs. So we intentionally use very little of the language (JS in my case), because the language is not the point of the course.
OOP and all these models of abstraction and code organisation come later, once they have a good grasp of the fundamentals.
This particular course I taught is only taken by CS freshmen, so that other commenter's remark (that we should teach a popular language) doesn't apply here.
That’s implying they will find it out, instead of having a finished project that can randomly crash with a slightly different input.
Also, the compiler is basically just a shorter eval loop.
But I agree with you that OOP should only come later (though using objects is inevitable in most languages)
Then, when learning Flow and Typescript, where I'm expected to have a meta understanding of typing itself, I was ready to go.
Oh no, for a beginner just setting up the environment is a huge hurdle. Sun's Java downloads page is utterly confusing, and the IDEs are monstrous and complex too. Past that, they have to learn about the JVM and compiling to JARs before they can even run their first program. Leave all that housekeeping to us seasoned, soul-crushed developers ;)
If we're starting to teach compiled, boilerplate-ridden laguages to beginners, why not jump straight to C++ or Rust?
I see static typing as a nice tool to help stop you making errors; but when I was trying to wrap my head around how to program I found it easier to not have to fight a compiler and allow myself to make mistakes.
Python excels as a teaching language.
JS, and its multitude of foot-guns, is not something I would call 'well designed'.
The syntax of Python is just way, way more straightforward. I do agree it may be a disadvantage for serious software engineering, but as a hobby? I will pick Python over others all day every day.
> But here too, Python is facing stiff competition from Julia
You severely overestimate the significance of Julia in this field. It's a great language, and I wish it were more popular, but Python still dwarfs it.
Students should learn early to use the right tool for the job, not reuse the same one just because it's already familiar.
IMO Python is a better first language because it's more approachable, and doesn't have the prototypal inheritance and other quirks unique to JS (not that it doesn't have quirks of its own, but most aren't important early on).