Homework Focus On Language 1
(1) Rauscher, F.H., Shaw, G.L., & Ky, K.N. (1993). Music and spatial task performance. Nature, 365, 611.
(2) McKelvie, P., & Law, J. (2002). Listening to Mozart does not improve children's spatial ability: Final curtains for the Mozart effect. British Journal of Developmental Psychology, 20, 241-258.
(3) Schellenberg, E. G., Nakata, T., Hunter, P. G., & Tamoto, S. (2007). Exposure to music and cognitive performance: Tests of children and adults. Psychology of Music, 35, 5-19.
(4) Jones, D. M., Alford, D., Macken, W. J., Banbury, S. P., & Tremblay, S. (2000). Interference from degraded auditory stimuli: linear effects of changing-state in the irrelevant sequence. Journal of the Acoustical Society of America, 108, 1082-1088.
(5) de Groot, A. M. B. (2006). Effects of stimulus characteristics and background music on foreign language vocabulary learning and forgetting. Language Learning, 56, 463-506.
(6) Dobbs, S., Furnham, A., & McClelland, A. (2011). The effect of background music and noise on the cognitive test performance of introverts and extraverts. Applied Cognitive Psychology, 25, 307-313.
(7) Hallam, S., Price, J., & Katsarou, G. (2002). The effects of background music on primary school pupils’ task performance. Educational Studies, 28, 111-122.
(8) Jäncke, L., & Sandmann, P. (2010). Music listening while you learn: No influence of background music on verbal learning. Behavioral and Brain Functions, 6, 1-14.
(9) Alley, T. R., & Greene, M. E. (2008). The relative and perceived impact of irrelevant speech, vocal music and non-vocal music on working memory. Current Psychology, 27, 277-289.
[SOUND] I thought I would finish up this section by taking a huge step back, and
as we've learned a bunch of ML already think about, is this the important stuff?
Is this how you learn a programming language?
And so I want to focus for just a minute on what does it take to learn a
programming language, and which part of that are we focusing on in this course?
So I like to think of it in terms of five different things.
If you want to learn a programming language and make yourself a better
programmer, you need to know the syntax. How do you write the language constructs?
If you don't know the syntax, you're not going to be able to write down programs.
I understand that, but you also need to know the semantics.
What are the type checking rules and evaluation rules?
If you don't know what programs mean, you're trying to write down different
things and hope to get the right answer. And that's why we keep focusing on what
do these concerts mean, what are the actual rules so we can reason about our
programs correctly. Something we haven't emphasized quite as
much is that you need so far at least is you need programming idioms.
It's not enough to know that there's an if then else expression that works in a
certain way you need to recognize when and if then else expression is the right
thing to use. We talked a little bit about the idiom of
using nested function bindings in order to have private helper functions that
couldn't be used somewhere else. That's different than just the semantics
of let expressions and function bindings. It's about representing, recognizing
typical patterns of use for certain features.
And then there's these other two libraries and tools.
So what facilities does the language provide to you that let's you do things
you either couldn't do on your own or would have to reimplement a lot of code
that somebody else has already provided for you?
So an example of a library that usually has to be provided for you is some way to
read and write files. If a language doesn't give you that on
some level, you're not going to be able to implement it yourself because you need
some way to access the file system. On the other hand, libraries for things
like data structures like trees or hash tables or lists are things that you
actually could define on your own. So far in ML we've used the lists that
have been provided to us, but we're going to learn enough features of ML to
know that we didn't need that, that we could have defined our own.
And then, finally, tools. These are things that language
implementations give you to make your job easier.
Maybe it's a REPL. Maybe it's something that helps you
format your code well. Maybe some of you have used debuggers in
other languages. I like to emphasize that tools are not
actually part of the language. There's something provided by an
implementation of the language, or just as a separate tool.
And as valuable as they are, they are separate from the language itself.
Okay. So these are five separate issues,
and in practice, if you want to be an effective programmer, you need to get
good at all five of these things, learning syntax, semantics, idioms, new
libraries, and tools. And I would like you to be good about
keeping these ideas separate. People often confuse them.
Oh man, it's like a pet peeve of mine when someone says, oh, I like the ML
language because it has a REPL. There is nothing to do with the ML
language that has a REPL. That's a tool that's provided by a
particular implementation of the language.
And it's good to keep those ideas separate in your head.
Okay so bringing it back to this course. This course focuses a lot on two and
three, on the semantics and the idioms. And I want to justify that for you so
that you continue on the course and understand why we're focusing on that.
I tend to not focus on syntax a lot, because as much as you have to know it,
it's usually not particularly interesting.
If you want to study American History you really need to know the American Civil
War ended in 1865, but that is not the interesting part.
That's the basic stuff that gets you to actually reason about theories and ideas,
and in our case, semantics. The other reason I usually am dismissive
toward syntax is that people obsess over subjective preferences.
And I am not going to sit here and tell you that this syntax is good, and that
syntax is bad. I'm not an expert of syntax any more than
you are. I do understand semantics, and I want to
teach that to you, using syntax only as necessary.
As far as libraries and tools they're really crucial,
but you're always going to have to learn new ones okay.
I'd rather teach you how to think about every programming language.
And the fact that we happen to have a REPL for ML, or some other language has a
debugger. There's good libraries for writing Red
programs, is really not our focus. And I truly believe that if you get good
at learn semantics and idioms of programming languages,
it actually makes you better at learning libraries and tools.
Okay, because it helps you say, oh how does this library work?
What these, these methods are functions that are being provided to me, what is
their semantics, and how are they typically used?
The same mental skills, intellectual tools you use for learning a language
become incredibly valuable for learning libraries.
We're not going to learn libraries, we're going to focus on the languages
themselves, and this has the unfortunate effect that it makes the programming
languages and the programs we write sometimes seem a little silly.
Right, here we are, we've watched all these videos and we know how to append
two lists, or take the max number from a list of numbers.
I know that real programming doesn't look like that, but I like to use the simple
example so that I can focus on the semantics.
And so I ask you not to judge the languages we use by the approach we are
taking in the course. If I taught all these same ideas in Java
or Python or Java Script, which I could do, those languages would look silly too.
Instead, I want to use these languages because they're the best vehicles for
focusing on semantics and idioms, and I assure you that there are ways to take,
say Ruby and use it for web programs, or Racket, and use it for real desktop
software and so on, and that's just not our focus.
Learn the semantics and the idioms in this course, and become a better software
person and a better computer scientist as a result.