1 Yozshulkree

Homework Focus On Language 1

References

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

Leave a Comment

(0 Comments)

Your email address will not be published. Required fields are marked *