23 ms·
I'm GP in this thread but I'll give my opinion just in case you're interested. I'm a huge proponent of static typing and I've even gone so far as to argue on o
by jolux 6y ago
I'm GP in this thread but I'll give my opinion just in case you're interested.
I'm a huge proponent of static typing and I've even gone so far as to argue on occasion that Haskell is simpler for beginners than Java. In programming pedagogy I think the most important goal for complete beginners is to get them confidently writing, running, and debugging programs as quickly as possible, to get the juices of programmatic thinking flowing. DrRacket is ideal for this.
To me the problem with statically typed languages is the amount of "stuff" that needs to be hidden or glossed over for beginners. You're not going to be teaching newbies all of what "public static void main(String[] args)" means right off the bat because you're going to bore them to tears and they won't understand why they should care about any of that yet. Similarly with Haskell any interesting program is going to have "main :: IO ()" at the top of it, and explaining all of what that means involves discussing monads as well.
With Python or Racket, there are fewer of these things. You can say "this is a function" and "this is a value" and even explain how those are kind of the same thing, without having to discuss types. In dynamic languages, there is really only one type. In static languages, there are many.
I would love to see an intro CS curriculum that was type-driven, but as an educator my experience is that people want to get their hands dirty ASAP, and I want to harness that energy. If I could figure out how to discuss types in a way that gave a solid basic understanding without getting lost in the weeds I would do it, but I haven't yet, and until then the simpler, dynamic languages are better to begin with.
- albntomat0 6y agoWhat are your thoughts on handwaving away "public static void main(String[] args)"? It's been a while, but when I learned programming initially, I remember being told something along the lines of "This tells the program where to start. Copy and paste it for now, and we'll to what it means later on." If there was a way to get the best of both worlds, that would obviously be ideal, but IMO, this is a fine sacrifice for students being deliberate about the types of their variables. Clearly new students shouldn't get crazy on types etc early on, but I'd definitely see someone trying '5' + 5 early on, or end up in a hard to debug situation like that. For example, returning a string from a function in one instance, and an integer in another. Instead of getting a failed addition at runtime later out and outside of function that causes the issue, the compiler can tell the student that they're returning a string, in a function that the student has explicitly stated returns an integer.
- jolux 6y agoMy CS prof taught Java similarly, even though I already knew it by the time I got to college. The distinction between compiling and running is nontrivial to understand, and I’m not sure how important it is right at the start. Python will throw a type error at runtime, Java will throw a type error at compile time. You can talk about what sorts of things you can do with strings and so on in a loose way without getting too in depth, for example. It may even help to mention them as types. But having the overhead of learning them first can often be too much, I think. Like I said, I don’t think this is the last word and I remain hopeful for better type-driven teaching strategies.