Hacker News new | ask | show | jobs
by ksml 1861 days ago
I think there were two main reasons: choosing a popular language (JS and python happen to be among the most popular, accessible languages) and pedagogical simplicity (it's nice to avoid burdening beginners with extra syntax when they're already struggling to learn other things). Some unscientific evaluation showed that students picked up static types just fine in our second programming class (which is in C++)

Personally, I think we should be teaching static types and I pushed for Typescript, but it didn't happen.

5 comments

> I think we should be teaching static types and I pushed for Typescript

Another option would be to introduce Python types:

    def square(x: int) -> int:
      return x*x
http://mypy-lang.org/examples.html
Is there something like DefinitelyTyped for Python? TypeScript only became useful once the ecosystem reached a critical mass of type definitions available for popular libraries.

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.

Not that I am aware of. You can create you own types like what has happened with boto3 [1]

I would assume as types become used more a definitely typed type project will happen on pypi.

[1] https://pypi.org/project/boto3-type-annotations/

Always an option to push for something like mypy. That'd at least give students exposure to types (even if they don't have to write them)
I started programming in Lua which is dynamically typed. It allowed me to experience why a type system would be nice. I'm sure if I had started with a typed language, I would have written it off as antiquated and unnecessary.
> it's nice to avoid burdening beginners with extra syntax when they're already struggling to learn other things

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.

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

Well, of course, but the point is that avoiding syntax is not a great criterion for defining the fundamentals of programming. A couple orders of magnitude more important is to decide what concepts are useful for beginning programmers to know.
I took it as "removing syntax left more space for other stuff"
I am sure I’m absolutely nowhere near your knowledge and expertise, but please bear with me sharing my opinion :)

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.

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

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

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?
But C# on the other hand is a very very complex language, with almost double the keywords compared to Java.
Yes, but I think the learning curve matters more, especially for students who are going to be mostly writing code, not reading existing projects.
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.
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.

> 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

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.

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

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)

I think wrapping all your code in OOP boilerplate is probably too much for an intro course. One of the nice things about Python is that hello world is `print("Hello world")`. No `public static void main(String[] args)`, no nothing. And then on top of that, you can add your functions and classes and whatnot, but it's easier to wrap your head around a zero-fluff entry point.
print "Hello world" - python 2 was/is even nicer in that regard.
> I think Java fits better as an introductory language

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?

Sun’s download page?? Also, vim is more than enough for beginners and there is hardly anything hard in javac Main.java && java Main. With a modern JDK java Main.java will compile and run it in one go even. Jars are absolutely not required.
Oracle! I guess I showed my age, and that the last time I developed on Java I had to use Eclipse and I still have PTSD from it.
Having gone the other way (starting with JS and moving into languages like Objective C), I actually disagree. Having a solid foundation in software writing helped me when I started to learn about the somewhat obtuse abstract concepts that tend to be coupled with learning strict typing.

Then, when learning Flow and Typescript, where I'm expected to have a meta understanding of typing itself, I was ready to go.