Since I've taught this class or one like it every year since 2005, and recently have been teaching it every semester, I find I get a lot of the same questions every semester about how the course is organized, etc. I think I answer most of these at some point in class, but students may find it useful to have these explanations all in one place.
General answer: I find ML to be the programming language that supports the pedagogical goals of the class with the least "baggage." Programming courses should never be about teaching a programming language. They should be about teaching programming. Choice of what programming language to use is not based on predicting what language students will use in some future situation but what will best support (and least harm) the task at hand. The intent is that the ideas and skills are transferable to other programming contexts. The main concepts in this course can be represented naturally in ML, and there's very little incidental stuff that students need to learn or ignore.
If you're wondering whether ML was chosen instead of another, specific language, see the following answers. (And I have nothing against these other languages, some of which I am a big fan of. This is only about their appropriateness for this course.)
Because in this course we're learning functional programming. Imperative and object-oriented programming (using Java and C) is covered in our other courses. Functional programming gives a counterpoint to these and fits well with discrete math.
Two reasons: Typing and syntax. First, understanding types is one of the most important programming goals, and I find it much easier to explain types in a language that is statically typed. Lisp, Scheme, and Python are dynamically typed. Moreover, ML as we use it in this course is very close to mathematical notation, so there is very little syntactic barrier to students who have never programmed before. The syntax of Lisp-family languages can be a serious impediment to newcomers.
It wouldn't make that much of a difference. I find ML a little cleaner/simpler than some of these. (And I know ML better.)
For pragmatic reasons. Grading every problem in a class of this size would take more time than the graders and instructor are reasonably able to give. Remember that the main point of homework is learning, not grades. I would be happy not to count homework at all and let it be up to you whether you get the practice or not. But alas, students need external motivation, and so we grade homework. I have found that spot-checking the homework submissions provides both sufficient feedback and sufficient motivation for students.
If you want to know whether your submission for a problem we didn't grade is correct, just ask during office hours.
Because it wouldn't be worth your time.
I know, it seems like it's better to get .5 on a homework than .75, since then you can redo it and get full credit. But remember, the main point of homework is for learning, not grades. The whole point of the re-turn-in system is to get you to learn the stuff you missed the first time. Getting missed points back is purely to provide incentive. I don't want the re-turn-in system to degrade into students doing busy-work like copying their answers over just to eke out a quarter point more. If you get .75 on a homework problem, that means you basically had it right but made some minor error which we have corrected for you. Learn from that mistake, but don't bother re-writing your answer with the correction. The missed .25 point is not a big deal.
By getting feedback from your proposal. The description of the project assignment doesn't give much guidance about how "big" the project is supposed to be for two reasons: It's hard to give a meaningful measure of project bigness, and some students are able to do more ambitious projects than others. I will help you determine whether you're doing enough stuff in your project when I give you feedback on your proposal and prototype. If you want more guidance, just ask.