SNOW logo
  • 로그인 회원가입 도움말 ENGLISH
컴퓨터과학과 프로그래밍 입문 (1): 강의 소개 및 목표 (Introduction and Goals of the Course )
[정규강의] 컴퓨터과학과 프로그래밍 입문 (Introduction to Computer Science and Programming) 1강/총15강
자막보기 자막감추기
메일보내기
트위터로 보내기
페이스북으로 보내기
북마크
소스복사
강의정보한글스크립트원문스크립트자막

강의소개  강의 전문보기

본 정규강의의 첫 강의로써 강의 목표와 계산(computation)에 대해 설명한다. 이어서 강의 내용으로는 데이터 타입, 연산자, 변수 등 가장 기초적인 내용을 공부하며 마무리한다.

* MIT OCW 강의들은 SNOW에 의해서 번역되고 있습니다. MIT대학, MIT대학의 교수진들 및 MIT OCW는 SNOW가 번역한 스크립트를 검토하거나 승인하는 일과는 관계가 없습니다. MIT대학 및 MIT OCW는 SNOW의 번역물에 관련한 보증은 없으며, 상품성에 대한 보증과 특수한 목적, 사용 또는 적용을 위한 적합성 보증 및 모든 다른 의무와 책임을 포함하되 그에 제한되지 않고, 모든 다른 명시적 또는 묵시적 보증을 대체하고 배제합니다. MIT OCW는 번역 오류에 대해 어떠한 책임도 없으며 번역의 부정확함에 따른 어떠한 오류나 결함은 전적으로 MIT OCW가 아닌 SNOW에게 책임이 있다는 것을 명시하는 바입니다. (These MIT OpenCourseWare course materials have been translated into Korean by SNOW. The MIT faculty authors, MIT, or MIT OpenCourseWare have not reviewed or approved these translations, and MIT and MIT OpenCourseWare makes no representations or warranties of any kind concerning the translated materials, express or implied, including, without limitation, warranties of merchantability, fitness for a particular purpose, non-infringement, or the absence of errors, whether or not discoverable. MIT OpenCourseWare bears no responsibility for any inaccuracies in translation. Any inaccuracies or other defects contained in this material, due to inaccuracies in language translation, are the sole responsibility of SNOW and not MIT OpenCourseWare.)

님이 영문스크립트를 등록 해 주셨습니다.
님이 한글스크립트를 등록 해 주셨습니다.

동영상을 보기 위해 필요한 기본 전공 지식
■ 대분류: JAVA Programming
■ 중분류: JAVA 이해
■ 소분류: JAVA 기본 요소

동영상에서 중점적으로 봐야 할 부분
● 데이터 타입
● 연산자
● 변수

참고서적
남궁성(2010), JAVA의 정석, 도우 출판
김승현(2006), JAVA Programming, 프리렉
월터 사비치(2011), Java: An Introduction to Problem Solving and Programming (6th Edition, Paperback), PearsonEducation


관련 동영상
<관련사이트>
MIT 컴퓨터 과학 및 프로그래밍 사이트
Oracle JAVA 관련 사이트
펼쳐보기

히스토리

프린트

*  
님이 등록 해 주셨습니다.
교수: 안녕하세요. 다시 한 번 해보세요. 안녕하세요. 
 
학생들: 안녕하세요. 
 
교수: 고마워요. 여기는 6.00, 컴퓨터 과학 입문과 프로그래밍 강의 시간입니다. 제 이름은 Eric Grimson이고, 저기 있는 John Guttag 교수와 이번 학기에 함께 이 강의를 진행할 것입니다. 여러분에게 몇 가지를 알려줄게요. 여러분은 이번 학기에 엄청난 힘을 갖게 될 것입니다. John은 마치 100년처럼 느껴 지는데 10년 동안 코스 6의 학과장이었고 저는 현재 학과장입니다. John은 대략 30년 동안 강의를 했습니다. 좋아요, 저는 젊은 사람입니다. 저는 25년 만 강의를 했거든요. 저는 John 보다 흰 머리가 적습니다. 제가 여러분에게 말하고 싶은 것은, 우리는 이 강의를 정말 진지하게 생각한다는 것입니다. 우리는 여러분들도 그렇게 생각하길 바래요. 그러나 우리는 모든 학생들이 컴퓨터에 대해 배우는 것이 학과에 있어서 매우 중요하다고 생각하고 이것이 이 강의에 대한 것입니다. 
 
제가 오늘 하려고 하는 것은 3 가지 입니다. 시작하겠습니다 – 사실, 시작한다고 말해서는 안됩니다, 저는 여러분이 이 수업을 어떻게 들어 나가야 하는지에 대해 알아야 할 약간의 자세한 사항들을 알려줄 것입니다. 이 강의의 목표가 무엇인지, 여러분이 다 배워서 학기를 마칠 때에 무엇을 할 수 있는지에 대해 말하고 싶군요, 그리고 나서 우리가 여기서 주요하게 다루고자 하는 컴퓨터적 사고의 개념과 도구에 대해 이야기하겠습니다. 우리는 여러분이 컴퓨터 과학자처럼 사고하는 방법을 배우는 것을 돕도록 노력할 것입니다. 그리고 계속 되는 강의의 나머지 동안의 수업과 강의의 목표에 대해 이야기하겠습니다. 
 
좋아요, 강의 목표부터 시작해 봅시다. 저는 여러분에게 두 단계의 목표를 줄 것입니다. 전략적인 목표는 다음과 같습니다: 우리는 코스 6을 전공하는데 관심 있는 1학년과 2학년 학생들이 학과에 쉽게 진입하도록 준비하는 것을 도와 주고 싶습니다. 특히 사전의 프로그래밍 경험이 없는 학생들에게요. 여러분이 그 범주에 속한다면, 패닉 상태에 빠지지 마세요. 여러분은 이해하게 될 것입니다. 우리는 여러분이 잘 진입하고 코스 6 커리큘럼을 확실하게 시작할 수 있도록 도와줄 것입니다. 그리고 잘 해내고 목표를 수행할 것입니다. 일반적인 생각들과는 달리, 우리는 여러분 모두가 코스 6을 전공할 거라고 기대하지 않습니다. 그래서 그 범주에 속하지 않는 학생들을 위해 우리가 할 두 번째 것은 코스 6을 전공할 계획이 없는 학생들이 적은 양의 코드를 쓰고 읽을 수 있는 능력에 정당하게 자신감을 갖도록 도와주는 것입니다. 
 
모든 학생들에게, 우리가 하고 싶은 것은 여러분이 기술적인 문제를 다룰 때 computation이 할 수 있고 할 수 없는 역할이 무엇인지 이해하도록 하는 것입니다. 그래서 여러분이 무엇을 할 수 있고, 무엇을 할 수 없는지, 그리고 여러분이 복잡한 문제를 다루기 위해 무엇을 사용해야 하는지에 대한 느낌을 가지고 떠나길 바랍니다. 
 
그리고 마지막으로, 우리는 모든 학생들이 쉽게 자리 잡기를 바랍니다. 여러분이 하고 싶으면, 여러분의 사무실이나 여름 방학 일자리를 구하는데 도전해 보세요. 왜냐하면 여러분은 컴퓨터적인 문제 해결을 위한 여러분의 능력에 있어서 적절한 수준의 자신감과 능숙함을 갖게 될 것이기 때문입니다. 이것이 전략적인 목표였습니다. 
 
이제, 이 수업은 주로 프로그래밍 경험이 없거나 적은 학생들을 대상으로 하고 있습니다. 결과적으로, 우리는 이 수업에 자격 미달인 학생들은 여기 없다고 생각합니다. 여러분은 모두 MIT 학생들입니다. 여러분은 모두 여기 있을 자격이 있습니다. 그러나 우리는 이 강의 수준을 넘는 학생들이 여기 없기를 바랍니다. 그리고 제가 무엇을 의미하는지 알겠습니까? 여러분이 프로그래밍 경험이 많으면, 이 강의는 아마 여러분에게 가장 좋은 강의가 될 수 없을 것입니다. 그리고 여러분이 그 범주에 든다면, 수업 후에 저나 John과 함께 여러분의 목표가 무엇인지, 여러분이 어떤 경험을 가지고 있는지, 그리고 우리가 여러분의 목표를 더욱 충족시키는 강의를 어떻게 찾을 수 있을지에 대해 이야기 했으면 합니다.  
 
우리가 이 수업에서 잘 하는 학생들을 원하지 않는 두 번째 이유는, 이것은 좀 못되게 들리겠지만, 두 번째 이유는, 잘 하는 학생들은, 저는 모르지만, 예를 들어 지난 5년 동안 구글에서 프로그래밍을 한 학생이 있으면 이 강의에서 쉽게 시간을 보낼 것입니다. 그러나 우리는 그런 학생을 원하지 않아요. 나머지 학생들에게 뜻하지 않게 자신감이 없어지게 할 수 있거든요. 우리는 여러분이 단지 경험이 없다고 무능하다고 느끼지 않았으면 좋겠어요. 그리고, 정말로 이 강의는 프로그래밍 경험이 없거나 적은 학생들을 대상으로 합니다. 그리고 다시 한 번 말하지만, 여러분이 그 범주에 들지 않는다면, 수업 후에 저나 John에게 이야기하세요. 그러면 우리는 여러분이 원하는 곳이 어디인지 알아내도록 도와줄 것입니다.  
 
좋아요. 이것들이 이 강의의 최고 수준의 목표들이었습니다. 이제 더욱 전략적인 단계에서 여러분이 이 강의에서 알아야 하는 것에 대해 이야기 해 봅시다. 우리는 여러분이 이 강의를 마칠 때 무엇을 할 수 있길 바랄까요? 이것은 여러분이 얻길 바라는 기술들입니다. 좋아요, 여러분이 얻었으면 하는 첫 번째 기술은, 여러분이 작은 규모의 프로그램을 짜기 위해 컴퓨터적 사고의 기본적인 도구들을 사용할 수 있었으면 합니다. 나중에 이 내용을 다시 할 텐데, 저는 그것을 컴퓨터적 사고라고 부를 것 입니다. 그리고 그럼으로써 여러분은 적은 양의 코드를 쓸 수 있을 것입니다. 그런데 여기서 적다는 것은 비판적인 게 아닙니다. 그것은 단지 여러분이 할 수 있는 것의 크기를 말하는 것입니다. 
 
이 강의를 마칠 때 여러분이 얻었으면 하는 두 번째 기술은 다른 사람이 쓴 프로그램을 이해할 수 있기 위해 컴퓨터적 도구들의 용어를 사용하는 능력입니다. 그래서 여러분이 코드를 쓸 수 있고, 읽을 수 있길 바랍니다.  
 
그런데, 마지막 기술은 엄청나게 중요한 것입니다. 여러분은 모든 것을 스스로 만들어 내길 바라지 않을 것이기 때문에, 다른 사람에 의해 만들어진 것을 볼 수 있고 그 내부에 무엇이 있는지, 제대로 작동하는지 그리고 여러분이 그것을 어떻게 구축할 수 있을지를 이해할 수 있길 바랍니다. 여기는 표절이 용인되는 몇 안 되는 곳 중의 하나입니다. 여러분이 쓰고 싶은 것을 만들어 내기 위해 다른 사람의 기술들에서 배우는 것은 나쁜 것이 아닙니다. 나중에 표절이 나쁜 경우를 다시 알려 줄게요.  
 
여러분이 하길 바라는 세 번째 것은 computation의 능력과 한계의 기본 사항들과 그것과 관련된 비용들을 이해하는 것입니다. 그리고 마지막 문장은 웃기게 들리겠네요. 여러분은 computation이 한계를 가지고 있다고 생각하지 않겠지만, 그렇지 않습니다. 컴퓨터로 계산될 수 없는 것들도 있습니다. 우리는 여러분이 이런 한계가 어디 있는지 이해하길 바랍니다. 그래서 여러분이 능력과 한계를 이해할 수 있었으면 합니다. 
 
그리고 마지막으로, 여러분이 이 강의에서 얻을 수 있는 마지막 전락적 기술은 과학적인 문제를 컴퓨터적 프레임과 연관 시키는 능력입니다. 그래서 여러분은 문제가 무엇인지 알면 그것을 컴퓨터적인 것으로 연관시킬 수 있을 것입니다. 
 
이제 여러분이 그것에 대해 생각하면, 이건 마치 문법 강의처럼 들리네요. 우리는 여러분이 읽도록 가르칠 것입니다. 여러분이 쓰도록 가르칠 것입니다. 여러분이 할 수 있는 것과 할 수 없는 것이 무엇인지 이해하도록 가르칠 것입니다. 그리고 가장 중요한 것은, 우리는 다른 분야의 문제가 무엇인지 아는 능력의 출발과 그것을 computation의 영역으로 연관시키는 방법을 가르칠 것입니다. 그래서 여러분이 원하는 것을 쓰고 읽을 수 있게 됩니다.  
 
좋아요, 몇 분 안에 우리는 computation이 무엇인지, 우리가 도구들을 어떻게 만들어 낼 수 있는지에 대해 이야기를 시작할 것입니다. 그러나 그것은 빼야 하는 내용입니다. 그것은 여러분이 다 마쳤을 때 이 수업에서 얻을 수 있는 것입니다.  
 
이제, 약 5분 동안 강의 관리, 이 수업에서 여러분이 알아야 할 자세한 사항들에 대해 이야기 해 봅시다. 여러분은 규칙이 무엇인지 알면 됩니다. 좋아요, 수업은 일주일에 2 시간 강의입니다. 여러분은 여기 있어야 하기 때문에 어디인지 언제인지 명백하게 알아야 합니다. 11시에 화요일과 목요일 입니다. 일주일에 한 번 1 시간의 설명이 있습니다. 금요일에요. 그리고 우리는 여러분이 그것을 어떻게 했는지 보러 곧 돌아올 겁니다. 그리고 일주일에 9 시간 수업 외 과제가 있습니다. 이 9 시간은 주로 문제 세트를 푸는 것입니다. 모든 문제 세트는 프로그래밍에 관련된 것입니다. 이번 학기에는 파이썬이라는 언어를 사용할 것입니다.  
 
이제, 여러분이 볼 첫 번째 것은 매우 쉬운 첫 문제 세트입니다. 사실, 이것은 아마 잘 못 되었을 겁니다. John, 그렇죠? 이것은 매우 쉬워요. 그리고 우리는 늘려 나갈 것입니다. 학기가 끝날 때쯤, 여러분은 꽤 복잡한 분제들을 다룰 것입니다. 그래서 여러분이 볼 것 중의 하나는, 우리는 라이브러리들과 다른 사람이 쓴 코드를 많이 사용할 것입니다. 이것은 여러분이 흥미로운 문제들을 다루게 할 것입니다. 저는 여러분이 가져 와서 쓸 수 있도록 할 것인데 여기 이 기술은 정말 중요한 것입니다. 여러분은 그 코드를 읽고 이해할 수 있어야 합니다. 물론 스스로 쓸 수도 있어야 하구요.  
 
좋아요. 두 번의 퀴즈가 있습니다. 이번 학기 동안, 날짜는 이미 계획 되었어요. John, 언제인지 살펴 보는 걸 잊었군요. 아마 10월 2일과 11월 4일일 겁니다. 강의 웹 사이트에 있습니다. 제 핵심은 강의 웹 사이트를 살펴 보라는 것입니다. 저기 있습니다. 여러분이 지금 퀴즈 날짜에 어려움이 있으면, 즉시 John이나 나에게 말하세요. 우리는 그 날짜 보다 미리 일정을 조정해 주겠습니다. 그러나 – 여러분이 예를 들어 그 날 결혼 한다면, 우리는 결혼 하러 일찍 자리를 뜨도록 해주겠습니다. 그러나 여러분은 퀴즈를 풀러 바로 돌아와야 합니다. 냉정한 사람들 이군요. 좋아요, 여러분이 어려움이 있으면, 우리에게 알려주세요. 
 
두 번째로, 여러분이 퀴즈를 위해 MIT가 입증하는 특별한 필요가 있으면, John이나 나에게 미리 말하세요. 적어도 퀴즈 2주 전에요. 다시 말하지만, 우리는 일정을 조정해 주겠습니다. 그러나 우리가 다룰 수 있도록 우리에게 충분한 주의를 주어야 합니다.  
 
좋아요, 퀴즈는 오픈 북입니다. 이 강의는 암기 하는 것이 아닙니다. 여러분이 사실을 얼마나 잘 외우는지가 아닙니다. 사실, 우리 나이를 고려해 볼 때, John과 나는 암기 시험에 약간 민감합니다, 그렇죠 John? 이것은 여러분이 무엇을 어떻게 외우는 가가 아니라 어떻게 생각하느냐에 대한 것입니다. 그래서 오픈 노트, 오픈 북입니다. 이것은 정말로 여러분의 생각하는 능력을 테스트하기 위함입니다. 
 
성적은 대략적으로 정해졌습니다. 제가 대략적이라고 말한 이유는 우리는 약간 몇씩 이동할 권리가 있기 때문입니다. 그러나 기본적으로 다음의 퍼센테이지입니다. 55%는 문제 세트이고, 45%는 퀴즈입니다. 그리고 퀴즈 2번과 기말 시험이 있다고 말했어야 하는데 잊어버렸군요. 기말 시험은 기말 기간에 있습니다. 퀴즈 퍼센테이지는 10%, 15%, 20%입니다. 그래서 45%입니다. 
 
좋아요. 다른 사항들입니다. 여기 제 목록을 살펴 봅시다. 첫 번째 문제 세트, 문제 세트 0은 이미 게시되었습니다. 이것은 정말 쉽습니다. 우리는 그것이 정말 쉬운 문제 세트가 되도록 했습니다. 그것은 기본적으로 여러분이 여러분의 기계에 파이썬을 로드하고 그것과 상호 작용하는 법을 이해하는 것을 확실히 하는 것입니다.  
 
첫 번째 문제 세트는 곧 게시될 것입니다. 그것은 또한 매우 지겹습니다. 다소 내 강의 같지만 John은 아닙니다. 그리고 우리는 여러분이 그것을 계속 하길 바랍니다. 걱정하지 마세요, 여러분이 계속 해 가면서 우리는 그것을 더욱 흥미롭게 만들 것입니다. 
 
그렇기는 하지만, 저는 문제 세트들이 치명적이지는 않다고 강조하고 싶군요. 우리는 여러분을 내쫓기 위해서가 아니라 여러분이 배우는 것을 돕기 위해 문제들을 사용할 것입니다. 그래서 여러분이 문제 세트를 만나면 그러지 마세요, 알겠죠? 도움을 찾으세요. 정신적인 도움이 될 수도 있고 조교가 될 수도 있습니다. 저는 조교를 추천합니다. 제 요점은 와서 누군가에게 말하라는 것입니다. 문제들은, 여러분이 옳은 길로 가면 그것을 풀기가 매우 간단할 것입니다. 여러분이 그럴듯한 길로 가지만 옳지 않은 길이라면, 때때로 어딘가에서 잡초에 잡힐 것입니다. 그러면 여러분은 돌아와야 합니다. 여기의 목표 중 일부는 그것이 엄한, 힘든 일이 되어서는 안 된다는 것입니다. 그것은 정말로 여러분이 배우는 것을 돕는 일이 되어야 합니다. 여러분이 도움이 필요하다면, John이나 나나 조교들에게 말하세요. 그것이 우리가 있는 이유입니다.  
 
좋아요. 우리는 주로 종이가 없는 것을 다룰 텐데, 그것이 웹 사이트가 있는 이유입니다. 웹 사이트를 체크하세요. 여러분이 알아야 할 것들에 관해서 모든 것들이 게시될 것입니다. 특히, 오늘 가세요. 여러분은 설명을 위해 등록하기 위해 폼을 채워 넣어야 합니다. 
 
설명은 금요일에 있습니다. 지금, 우리는 9:00, 10:00, 11:00, 12:00, 1:00, 2:00 시로 계획하고 있습니다. 우리는 이 중 하나는 뺄 것입니다, 강의 크기에 맞춰서요, 알겠죠? 불행히도, 우리는 여러분을 움직여야 할 권리가 있습니다. 제 생각엔 9시는 엄청나게 인기 있는 시간이 되지는 않을 것 같군요. 그러나 여러분이 저를 놀라게 할 수도 있습니다. 그렇지만, 가서 등록하세요. 어떤 시간이 여러분에게 좋은지 알아야 합니다. 다시 말하지만, 우리는 여러분을 이동할 권리가 있습니다. 균형을 맞춰야 하지만 우리는 여러분이 우리 보다 여러분의 일정에 맞는 것을 찾길 바랍니다. 
 
좋아요. 다른 것입니다. 필요한 교재는 없습니다. 교재가 없어서 불안하다면, 여러분은 정말 교재를 가져야 합니다. 한 가지 추천한 것이 있습니다. – 사실 그 단어를 다시 사용해야겠군요, John, 교재를 알고 싶으면 강의 웹 사이트에 가세요. 저는 우리가 글로 전율을 느낀다고 생각하지 않습니다. 우리는 아마 파이썬에서 최고라는 것을 알게 될 것입니다. 괜찮습니다. 여러분이 필요하다면, 거기 있습니다. 그러나 우리는 기본적으로 어떤 특정 교재에 의존하지 않습니다. 
 
좋아요. 그것과 관련하여: 출석은 명백히 의무적인 것이 아닙니다. 여러분은 더 이상 고등학생이 아닙니다. 저는 우리가 여러분의 웃는 얼굴을 보는 것을 좋아한다고 생각합니다. 또는 여러분이 매일 웃지 않는다면 적어도 여러분의 얼굴을 보는 것을요. 제가 말하고 싶은 핵심은 우리는 지정된 자료에 없는 많은 내용들을 다룰 것입니다. 그리고 우리는 강의 하나씩과 연관해서 자료를 올릴 것입니다. 여러분이 오늘 나오지 않기로 선택했다면 – 아 미안해요, 여러분은 오늘 오기로 선택했습니다. 여러분이 나중에 오지 않기로 선택한다면 – 우리는 이해할 것입니다. 그러나 조교들이 여러분이 자료에 있는 내용이나 수업에서 다룬 것과 매우 간단한 것을 질문하면 인내심이 아주 많지 않을 것이라는 것 또한 이해하세요. 알겠죠? 우리는 여러분이 책임감 있게 행동하길 바랍니다. 우리도 그렇게 할 것이고요. 좋아요.  
 
우리가 이야기할 마지막 내용은 우리는 수업 노트를 다루지 않을 것입니다. 이제 이것은 가혹한 방법으로 들리겠군요. 왜 그런지 말해 주겠습니다. 제가 아는 모든 공부는, 그리고 존이 아는 모든 사람은 배우는 것에 대해 학생들은 필기를 할 때 가장 많이 배운다고 강조 합니다. 아이러니하게도, 학생들이 그것을 전혀 들어다 보지 않더라도요. 좋아요. 필기의 과정은 여러분 뇌의 절반을 사용합니다. 그리고 사실 여러분이 배우는 것을 돕습니다. 그래서 필기는 정말 중요한 것이지요. 그러므로 우리는 노트를 나눠 주지 않을 것입니다. 우리가 대부분 강의에서 나눠줄 것은 우리가 할 코드 예제 핸드아웃입니다. 저는 오늘 가져 오지는 않았어요. 오늘 많은 코드를 다루지 않을 것이니까요. 나중에 할 것입니다. 노트는 말이 안됩니다. 제 생각으로는, 강의 밖에서요, 그렇죠? 여러분이 11:04에 와서 복사본을 가지고 나가서 더 잠을 자는 것이 아닙니다. 우리가 추천하는 것은 여러분이 노트를 사용해서 어떻게 되어 가는지 이해하기 위해 스스로 주석을 다는 것입니다. 우리가 수업 노트를 제공하지는 않을 것입니다. 여러분을 돕기 위해 스스로의 노트를 가지길 바랍니다. 여러분 스스로 배우는 과정에 박차를 가하세요.  
 
좋아요. 그리고 마지막으로, 저는 존, 저와 모든 스탭들, 우리의 일은 여러분이 배우는 것을 돕는 것이라는 것을 강조하고 싶군요. 그것이 우리가 있는 이유입니다. 우리는 그것에 대해 흥분됩니다. 여러분이 막히거나, 어려움에 분투하거나, 무엇에 대해 확신이 없다면, 물어보세요. 우리는 독자를 고려하지 않으니 여러분이 언제 어려워하는지 알 수 없습니다. 여러분 얼굴에 표현이 없으면요. 우리는 그것을 알려줄 여러분의 도움이 필요합니다. 그러나 모든 조교들, 여기 첫 줄에 앉아 있는 사람들은 도우러 여기 왔습니다. 와서 물어 보세요. 동시에, 조교들도 또한 학생들이라는 것을 기억하세요. 여러분이 읽거나, 강의에 오거나 구글을 사용해서 쉽게 알 수 있는 것을 와서 질문하면, 조교들은 인내심이 없어질 거에요. 그러나 여러분이 정말 개념적으로 어려운 것을 이해하도록 돕는 것이 조교들이 여기 있는 이유이고 우리가 있는 이유입니다. 그러니 와서 우리와 이야기합시다. 
 
좋아요. 이것이 여러분이 알아야 할 내용의 서두였습니다. 존, 추가할 것이 있나요? 
 
GUTTAG 교수: 두 가지만요. 이번 학기에, 여러분의 수업은 OpenCourseware를 위해 녹화됩니다. 여러분의 이미지가 녹화되어 웹에 게시되는 것을 원치 않으면, 뒤의 세 줄에 앉으세요.  
 
GRIMSON 교수: 아, 고마워요. 잊어버렸군요.  
 
GUTTAG 교수: 왜냐하면 카메라가 찍을 것이니까요. 저는 여러분이 모두 훌륭한 외모를 가졌다고 생각하니까 MIT의 좋은 이미지를 심어주세요. 그러니 촬영되는 것을 편하게 생각하세요. 
 
GRIMSON 교수: 제가 다시 말하면, 여러분이 원하면 뒤로 가세요. 저는 누가 움직이는지 보지 않겠습니다. 네. 좋습니다. 고마워요, 존. 
 
GUTTAG 교수: 제가 말하고 싶은 다른 것은 설명 시간이 매우 중요하다는 것입니다. 강의나 자료에 없는 것을 설명 시간에 다룰 것이니 참석하도록 하세요. 
 
GRIMSON 교수: 좋아요. 고마워요, 존. 질문할 것 있나요? 지루하다는 것 압니다. 그러나 우리는 해야 하니까 여러분은 기본 원칙들이 무엇인지 알아두세요. 
 
좋아요. 네. computation에 대해 이야기 해 봅시다. 제가 말했듯이, 우리의 전략적 목표와 전술적 목표들은 여러분이 컴퓨터 과학자처럼 생각하는 것을 돕는 것입니다. 다시 말해, 우리는 여러분에게 컴퓨터가 여러분이 원하는 것을 할 수 있도록 하는 기술을 주는 것입니다. 그리고 수업이 끝날 때, 여러분이 기술적인 문제와 직면할 때 마다 여러분의 첫 본능은 “내가 어떻게 그것을 푸는데 도움이 되는 코드를 짤 수 있을까?”일 것입니다. 
 
그래서 우리는 여러분이 컴퓨터 과학자처럼 생각하는 것을 도울 것입니다. 좋아요. 그리고 그것은 흥미로운 문장입니다. 컴퓨터 과학자처럼 생각한다는 것은 무엇을 의미할까요? 자, 봅시다. 여러분이 이 강의에서 가지고 갈 주요한 지식은 컴퓨터적인 문제 해결의 개념입니다. 즉, 컴퓨터적인 생각의 모드로 생각하는 능력입니다. 그리고 많은 입문 강의들과는 달리, 결과적으로, 암기하는 능력은 여러분에게 도움이 안 될 것입니다. 여러분이 사용하고 싶은 도구들의 개념들을 정말로 배우는 것입니다. 이 세계에서 컴퓨터적인 생각의 모드라는 것은 무엇을 의미할까요? 여러분이 VC가 여러분에게 자금을 대도록 설득하려고 노력 할 때 여러분이 사용하는 허세 부리는 문구 같이 들리는 군요. 좋아요. 이것에 대한 답은, 우리는 정말로 다른 질문, 연관된 질문을 해야 합니다; 그래서, computation이 무엇인가요?  
 
이상한 문장 같네요, 그렇죠? Computation이 무엇인가요? 그리고 이렇게 하는 이유는 가능한 한 기계 즉 컴퓨터를 컴퓨터적인 사고와 분리하여 질문에 답하고 싶기 때문입니다. 좋아요. 인공품은 이것을 몰아가는 것이 되어서는 안됩니다. 그것은 “computation을 한다는 것은 무슨 의미일까?”의 개념이 되어야 합니다.  
 
이제, 그것에 대한 답은, 저는 한 단계 뒤로 가겠습니다. 그리고 “지식이란 무엇인가?”와 같은 철학 질문처럼 들리는 것을 제기할 것입니다. 그리고 여러분은 약 2분 안에 왜 제가 이것을 했는지 알게 됩니다. 그러나 저는 지식을 적어도 두 카테고리로 나눌 수 있다고 제안할 것입니다. 좋아요, 그러면 지식은 무엇인가요? 그리고 제가 나누려고 하는 두 카테고리는 서술적인 지식과 명령하는 지식입니다. 
 
좋아요. 이 세계에서 서술적인 지식은 무엇인가요? 그것은 사실의 진술이라고 생각하세요. 그것은 진실의 주장입니다. 정치적인 기간에는, 사용하기 정말 위험한 문구입니다, 그렇죠? 그러나 그것은 사실의 진술입니다. 저는 정치적인 말과는 떨어질 것입니다.이것의 예를 들어보죠. 좋아요. 여기에 서술문이 있습니다. x의 제곱근은 y이고 y는 x를 제곱한 것이고, y는 양수 입니다. 여러분은 모두 알 것입니다. 그러나 여기서 제가 여러분에게 보여주려고 하는 것은 사실의 진술이라는 것입니다. 그것은 정의 입니다. 그것은 공리 입니다. 그것은 여러분이 제곱근을 찾는 것을 도와주지 않습니다. x가 2라고 한다면, 저는 2의 제곱근이 무엇인지 알고 싶습니다. 여러분이 괴짜라면 1.41529 또는 어떤 젠장 맞을 것이라고 할 수 있지만, 일반적으로, 이것은 여러분이 제곱근을 찾는데 도움이 되지 않습니다. 가장 가까운 것은 여러분 테스트 하도록 하는 것입니다. 여러분이 하버드 스퀘어를 배회하다가 실직 중인 하버드 졸업생을 보면, 그들은 제곱근의 예제들을 나눠주고 있을 것입니다. 그들은 여러분에게 예제를 주고 여러분은 2, 1.41529 또는 어떤 것의 제곱근이 무엇인지 알기 위해 테스트해 볼 수 있습니다. 하버드 유머로도 웃기지 못했군요, 존. 여기서 곧 멈춰야겠어요, 그렇죠? 좋아요, 제가 여기서 말하려고 하는 것은 무엇입니까? 그것은 – 네, 정확합니다. 우리는 그것으로부터 떨어져 있습니다. 정말 빠르게, 특히 카메라가 돌아가면서요. 
 
좋습니다. 제가 말하려고 하는 것은 무엇입니까? 여러분이 무엇을 테스트 하는지 알려주지만 여러분에게 어떻게 하는지는 알려주지 않습니다. 
 
그리고 이것은 명령하는 지식이 무엇인지 입니다. 명령하는 지식은 무언가를 어떻게 추정하는지에 대한 서술입니다. 명령하는 지식의 예를 들어보겠습니다. 좋아요, 이것은 사실 제곱근을 계산하는 명령하는 지식의 매우 오래된 예입니다. 저는 바빌로니아 사람들이 이전에 알았을 거라고 믿지만 그것은 Heron of Alexandria 덕분입니다. 그러나 여기 명령하는 지식의 예가 있습니다. 알겠죠? 저는 추측으로 시작해보겠습니다. 이것을 g라고 부르겠어요. 그리고 제곱된 g가 x와 가까우면, 멈추세요. 그리고 g로 돌아옵니다. 이것은 충분히 좋은 답변입니다. 이와 달리, g와 x 나누기 g를 구하고, 둘을 더하고, 나눔으로써 새로운 추측을 해보겠습니다. 그러면 여러분은 g와 x 나누기 g의 평균을 구할 수 있습니다. 어떻게 그렇게 되는지에 대해서는 걱정하지 마세요. Heron이 이것을 알아냈습니다. 그러나 그것은 저에게 새로운 추측을 주었고 다시 반복하겠습니다. 
 
그것이 레시피입니다. 그것은 단계들의 서술입니다. 그것이 무엇을 가지는지 주목하세요, 그것은 우리가 사용하고 싶은 좋은 것의 다발을 가집니다, 그렇죠? 이것은 제가 순서대로 한 특정한 명령들의 순서입니다. 제가 테스트하는 방법에 따라, 그리고 시험의 가치에 따라, 저는 제가 명령의 순서 중 어디 있는지 바꿀 수 있습니다. 그리고 마지막 시험은 제가 언제 다 했고 답이 무엇인지 입니다. 이것은 여러분에게 제곱근을 찾는 방법을 알려줍니다. 이것은 방법의 지식입니다. 이것이 명령하는 지식입니다. 
 
좋아요. 이것은 computation이 기본적으로 무엇인지에 대한 것이었습니다. 우리는 이 과정을 캡쳐할 방법을 가지고 싶습니다. 좋아요, 이제 흥미로운 질문이 있겠군요. “제가 어떻게 computation 세트를 캡쳐할 기계적인 과정을 만드나요?” 그래서 저는 그것을 하는 쉬운 방법이 있다는 것을 제안하려고 합니다. 제가 칠판에 여기 잘못된 순서로 했군요. 제가 할 수 있는 방법 중 하나는 여러분이 이것을 하는 작은 회로를 만든다고 상상하는 것입니다. 제가 그 안에 저장된 값의 몇 가지 성분을 가지고 있다면, 저는 그것을 이동할 철사를 가지고 있습니다. 저는 더할 작은 것, 나눌 작은 것, 그리고 테스트할 것도 가지고 있습니다. 이 computation을 실제로 할 작은 회로를 만들 수 있습니다. 
 
좋아요. 이상하게 들리겠지만, 이것은 사실 최초의 컴퓨터의 예입니다. 왜냐하면 최초의 컴퓨터는 우리가 고정된 프로그램 컴퓨터라고 부르는 것이었습니다. 그것은 특정한 computation을 하기 위해 설계 된 일종의 전기 회로망을 의미합니다. 그리고 그것이 그들이 하는 것입니다: 그들은 특정한 computation을 합니다. 여러분은 이것을 많이 봤죠, 그렇죠? 이것의 좋은 예는 계산기 입니다. 이것은 기본적으로 고정된 프로그램 컴퓨터의 예입니다. 그것은 연산을 합니다. 여러분이 그것에서 비디오 게임을 하고 싶다면, 행운을 빕니다. 여러분이 그것에 워드 작업을 하고 싶다면, 행운을 빌어요. 그것은 특정한 일을 하기 위해 설계되었습니다. 그것은 고정된 프로그램 컴퓨터입니다. 
 
사실, 일찍이 매우 흥미로운 많은 것들이 이런 특징을 비슷하게 가졌습니다. 예를 들어 보겠습니다: 저는 이것을 어떻게 발음하는지 전혀 모르겠어요, Atanasoff, 1941. 최초의 컴퓨터적인 것 중의 하나는 Atanasoff라는 남자에 의해 설계된 것입니다. 그리고 이것은 기본적으로 선형 방정식을 푸는 것입니다. 여러분이 1801년, 좋아요, 또는 1806년이나 여러분이 하고 싶은 언제든 간단한 것입니다. 이것이 하는 모든 것은 이 방정식들을 푸는 것이었습니다. 
 
제가 초기 컴퓨터의 가장 좋아하는 예들 중 하나는 Alan Turing에 의한 것입니다. 그는 위대한 컴퓨터 과학자 중 한 명입니다. 코드를 파괴하는 것으로 설계 되었던 bombe라고 불립니다. 그것은 사실 세계 2차 대전 동안 독일의 수수께끼 같은 코드를 알아내기 위해 사용되었습니다. 그리고 그것이 설계 된 것은 특정한 문제를 풀기 위해서였습니다.  
 
제가 말하려는 핵심은 고정된 프로그램 컴퓨터는 우리가 시작한 것이지만 그것은 우리가 어디에 있고 싶어 하는지를 알려주지 않습니다. 우리는 문제 해결의 이 아이디어를 캡쳐하고 싶습니다. 그래서 우리가 어떻게 할 수 있을지 봅시다. 심지어 이 틀 내에서, 단계들의 세트로써 computation의 서술이 주어졌을 때, 그 생각에서 저는 그것을 할 회로를 만들 수 있습니다. 여러분에게 만들 훌륭한 회로가 무엇인지 제안해보겠습니다. 
 
다음의 특징을 가지는 회로를 만든다고 가정해 보세요: 이 회로의 입력은 어떤 다른 회로 도표가 될 수 있다. 어떤 computation을 위한 회로 도표를 주세요, 그것에 회로를 주고, 그 회로는 훌륭하게 회로 도표처럼 스스로 변경할 것입니다. 무엇을 의미하냐면, 그것은 계산기처럼 작동합니다. 또는 Turing의 bombe처럼 작동합니다. 또는 제곱근 기계처럼 작동합니다.  
 
회로가 무엇과 같아 보입니까? 여러분은 주위를 배회하는 작은 로봇을 상상할 수 있습니다, 그렇죠? 철사를 당기고 성분들을 떼어 내서 그것들을 함께 쌓아둡니다. 여러분은 어떻게 회로 도표를 가지는 회로를 만들고 그 회로 같이 작동하는 기계를 만들 수 있나요? 훌륭한 도전으로 들리는군요.  
 
제가 게임을 약간 바꿔보겠습니다. 대신, 저는 레시피 즉 단계 순서의 설명을 가지는 기계를 원합니다. 그것의 입력을 가지고, 기계는 이제 레시피에 설명된 대로 작동할 것입니다. 그것을 변경하세요, 작동해 보세요. 여러분이 단어를 사용하길 원해도 그것은 computation 하는 방법을 바꿀 것입니다.  
 
이것은 훌륭합니다. 그리고 존재합니다. 이것은 인터프리터라고 불립니다. 이것은 모든 컴퓨터의 기본 핵심입니다. 이것이 하는 것은, 게임을 바꿔봅시다. 이것은 이제 저장된 프로그램 컴퓨터의 예입니다. 저장된 프로그램 컴퓨터에서, 그것이 의미하는 것은 제가 컴퓨터에 제가 실행하길 원하는 과정을 설명하는 명령의 순서를 줄 수 있는 것입니다. 그리고 기계 내에서, 그리고 우리가 이야기 하는 것들은 레시피에 설명된 대로 실행 될 순서를 허용하는 과정이 있습니다. 그래서 그것은 제가 레시피들 중 하나라고 설명하는 것처럼 작동합니다. 
 
좋아요. 그것은 사실 가지면 정말 좋은 것처럼 보이는 군요. 여러분에게 그것이 기본적으로 어떻게 보이는지 보여주겠습니다. 저장된 프로그램 컴퓨터 내부에, 우리는 다음과 같은 것을 가집니다: 우리는 메모리를 가집니다, 이것은 두 개가 연결되어 있습니다: ALU 라는 제어 장치, 연산 논리 장치입니다. 이것은 입력을 가져오고 출력을 내보냅니다. 그리고 저장된 프로그램 컴퓨터 내부에, 잠시만요, 여러분은 다음을 가집니다: 여러분은 명령의 순서를 가집니다. 그리고 이 모든 것은 거기에 저장됩니다. 차이를 주목하세요. 레시피, 즉 명령의 순서는 사실 안에 쓰여 있고 데이터처럼 다뤄집니다. 그것은 기계의 메모리 내부에 있습니다. 우리는 그것에 접근하고, 그것을 변경하고, 그것을 해석할 수 있을 뿐 아니라 새 코드를 만들기 위해 그것을 사용할 수도 있습니다. 이 컴퓨터에 들어가는 다른 한 부분은 -- 저는 PC를 어디에 두는지 기억을 못하겠습니다, 존, 제어? ? ALU? 분리? 저는 그것을 분리할 것입니다. 여러분은 명령 번지 레지스터(program counter)라고 하는 것을 가집니다. 
 
그리고 여기에 computation의 기본이 있습니다. 그 명령 번지 레지스터는 메모리의 어떤 위치를 가리킵니다. 일반적으로 순서 상의 첫 번째 명령을요. 그런데, 그 명령들은 매우 간단합니다: 그것들은 메모리 두 영역의 값을 가져와서 여기 작은 전기 회로망의 승수를 빨리 살펴보고 그것들을 메모리의 어딘가에 다시 가져다 놓습니다. 또는 메모리의 그 값을 가져와서 간단한 연산을 하고 메모리에 다시 가져다 놓습니다. 이 명령을 실행하면 레지스터는 1만큼 이동하고 우리는 다음 1로 이동합니다. 우리는 명령을 실행합니다. 다음 1로 이동합니다. 오 예, 이것은 그것과 매우 같습니다.  
 
다른 명령들 중 몇몇은 테스트를 포함합니다: 그들은 이렇게 말합니다, 그것이 옳습니까? 그리고 테스트가 옳으면, 이 명령 번지 레지스터의 값을 메모리의 다른 장소를 가리키도록 바꿉니다. 명령 순서 상의 다른 곳으로요. 그리고 여러분은 계속 처리할 것입니다. 결과적으로 여러분은 희망을 갖고 멈춥니다. 그리고 값이 나오면 여러분은 다 한것입니다.  
 
이것이 컴퓨터의 핵심입니다. 이제 약간 잘못 말한 것이 있군요. 제어의 과정은 매우 흥미롭습니다. 그러나 컴퓨터의 핵심은 단지 우리가 초기 명령들의 순서에서 우리의 설명, 레시피를 만드는 이 간단한 개념입니다. 그리고 나서 우리는 제어의 흐름을 가집니다. 제어의 흐름은 제가 방금 설명한 대로 입니다. 그것은 명령의 순서를 따라 이동합니다. 때때로 우리가 움직이면서 어디 있는지 바꿉니다. 
 
좋아요. 여러분이 이것으로부터 떨어지길 바라는 것은 이것을 레시피로 생각하는 것입니다. 그리고 이것이 정말 프로그램이 무엇인지 입니다. 이것은 명령의 순서입니다. 이제, 남은 것 중 하나는, 좋아요, 여러분은 초기 명령들에 의해 만들었습니다. 그래서 질문 중 하나는, 자, 사용할 옳은 초기 명령들은 무엇입니까? 그리고 유용한 것들 중 하나는 우리가 사실 여러분이 사용하고 싶은 초기 명령들 세트는 매우 간단하다는 것을 압니다.  
 
좋아요. 그러나 그것을 하기 전에, 왜 이것이 레시피인지에 대한 생각을 집으로 가져가겠습니다. 제가 모든 것을 설명할 수 있는 초기 명령 세트를 가진다고 가정하면, 저는 제가 무엇을 만들 수 있을지 압니다. 자, 제가 실제 레시피와 상당히 비슷한 것을 해보겠습니다. 그러니까, 실제 레시피입니다. 저는 모릅니다. 여섯 개의 달걀을 분리합니다. 무언가를 하세요. 저으세요 – 미안해요, 흰자를 뻑뻑해질 때까지 섞으세요. 마지막 테스트가 옳을 때까지 무언가를 하세요. 노른자를 가지고 설탕과 물을 넣고 섞습니다. – 아닙니다. 설탕과 밀가루가 아마 제가 원하는 것인 것 같네요. 설탕과 물은 여기서 흥미로운 게 아닙니다. 그것들을 다른 것과 섞으세요. 그것의 순서대로 합니다.  
 
일반적인 레시피는 사실 초기 명령들의 작은 세트에 기반합니다. 그리고 그 초기 명령들의 세트를 가지는 좋은 주방장, 요리사는 무한한 훌륭한 요리들을 만들어 낼 수 있습니다. 같은 일이 프로그래밍에서도 옳습니다. 좋아요. 초기 명령들의 고정된 세트가 주어졌을 때, 좋아요, 좋은 프로그래머는 무엇이든 프로그램을 짤 수 있습니다. 여러분은 그 초기 명령들의 세트에서 캡쳐할 수 있습니다. 
 
좋아요, 제가 시작했을 때 질문은 “옳은 초기 명령들은 무엇인가?”입니다. 그래서 여기 약간의 작은 역사가 있습니다. 1936년에, 같은 사람 Alan Turing가 여섯 개의 간단한 초기 명령들을 가지고 보여주었습니다. 기계적은 과정으로 설명될 수 있는 것은 사질 알고리즘적으로 이 여섯 개의 초기 명령들을 사용해서 프로그래밍 될 수 있습니다. 
 
잠시 그것에 대해 생각해 보세요. 그것은 믿을 수 없는 문장입니다. 여섯 개의 초기 명령들을 가지고 저는 세상을 지배할 수 있습니다. 여섯 개의 초기 명령들을 가지고 저는 포든 것을 프로그래밍 할 수 있습니다. 그것의 정말 흥미로운 몇 가지 결과들 중 하나는 여러분이 하나의 프로그래밍 언어에서 할 수 있는 것은, 여러분이 다른 프로그래밍 언어에서 할 수 있다는 것입니다. 그리고 더 나은 프로그래밍 언어는 없습니다 – 사실, 확실히 옳지는 않아요, 특정한 일을 할 때 더 나은 것이 있으니까요 – 그러나 여러분이 C에서 할 수 있는 것을 포트란에서 할 수 없는 것은 없습니다. 이것은 Turing 호환성이라고 합니다. 여러분이 하나로 할 수 있는 것은, 다른 하나로도 할 수 있습니다. 그것은 근본적인 결과에 기반합니다.  
 
좋아요. 이제, 다행히도 우리는 Turing의 여섯 가지 초기 명령들로 시작하지 않을 것입니다. 이것은 매우 고통스러운 프로그래밍입니다. 왜냐하면 그것은 “이 값을 가져다가 이 테이프에 써라” 수준 보다 아래이기 때문입니다. 무엇보다도, 우리는 컴퓨터에 더 이상 테이프가 없습니다. 그리고 있다고 하더라도, 우리는 그 수준의 프로그래밍을 하길 원치 않습니다. 프로그래밍 언어로 우리가 보는 것은 고 수준의 추상적인 것을 사용하는 것입니다. 초기 명령 세트가 넓긴 하지만 같은 근본적인 것을 가집니다. 여섯 가지 초기 명령들로, 여러분은 할 수 있습니다. 
 
좋아요. 그래서 우리가 여기 어디에 있죠? 우리가 말하고 있는 것은, computation을 하기 위해, 우리는 레시피를 설명하길 원하고, 초기 명령들에 만들어진 단계의 순서를 설명하길 원합니다. 그리고 우리가 계속 하면서 거치는 단계의 이 순서들인 제어의 흐름을 설명하고 싶습니다. 
 
우리가 실제 프로그래밍에 대해 시작하기 전에 필요한 마지막 것은, 우리는 이 레시피들을 서술해야 한다는 것입니다. 좋아요, 그리고 레시피들을 서술하기 위해, 우리는 언어가 필요합니다. 우리는 초기 명령들이 무엇인지 뿐만 아니라 우리가 어떻게 그것들을 그 언어에서 의미 있게 만드는지도 알아야 합니다. 언어요. 우리가 할 것입니다. 좋아요. 이제, 다음과 같습니다 – 저는 모르겠군요, 존, 수백? 수천? 개의 프로그래밍 언어들요? 적어도 수백 개의 프로그래밍 언어들이 있습니다. 
 
JOHN GUTTAG 교수: [안 들림] 
 
ERIC GRIMSON 교수: 맞아요. 고마워요. 그것들은 모두 장점과 단점이 있습니다. 저는 인정해야 합니다, 여기서 제 경력에서, 저는 적어도 세 개의 언어를 가르쳤습니다. 당신은 더 많이 가르쳤다고 생각되는데요, 5 개나 6 개 되나요, 존? 우리는 모두 아마 더 만은 언어로 프로그램을 해봤고, 우리가 그 언어들을 가르친 이래로 적어도 그 보다 더 많이 프로그램을 해봤습니다. 
 
여러분이 깨닫길 바라는 것들 중 하나는, 최고의 언어는 없다는 것입니다. 적어도 제가 주장하는 것은 그렇습니다, 저는 존도 동의할거라고 생각합니다. 우리는 모두 우리 스스로의 가장 나쁜 언어 후보들을 가지고 있습니다, 그런 것들이 있거든요. 그렇지만 가장 좋은 언어는 없습니다. 그렇죠? 그들은 모두 다른 것들을 서술하는 것입니다. 그렇게 말하지만, 어떤 것은 다른 것보다 어떤 일에 더욱 적합할 순 있습니다.  
 
아마 MATLAB에서 프로그램 된 MATLAB에 대해 들어 본 학생 있나요? 그것은 벡터와 행렬 그리고 그 틀에서 쉽게 캡쳐될 수 있는 것을 가지고 할 수 있는 좋은 훌륭한 것입니다. 그러나 MATLAB에서 하는 것은 정말 고통스럽습니다. 그래서 그런 일을 하는데 MATLAB은 좋습니다. 
 
예를 들어, C는 데이터 네트워크를 제어하는 프로그래밍을 하는데 좋은 언어입니다. 
 
저는 그렇고, 존은 제가 자주하는 것을 놀리는데, 저는 오래 된 Lisp 프로그래머입니다. 그리고 이것이 제가 훈련된 것입니다. 그리고 저는 Lisp와 스키마와 같이 되었습니다. 그것은 제멋대로 구조된 데이터 세트를 가지는 문제를 다룰 때 좋은 언어 입니다. 이것은 특히 그 때 좋습니다. 
 
그래서 제가 여기서 말하려는 요점은 특정하게 가장 좋은 언어는 없다는 것입니다. 우리가 할 것은 단지 우리가 이해하도록 하는 언어를 단지 사용하는 것입니다. 그래서 이 강의에서, 우리가 사용할 파이썬이라는 언어가 있습니다. 꽤 새로운 언어인데, 인기를 얻어 가고 있습니다. 그것은 다른 언어들의 성분을 많이 가지고 있습니다. 왜냐하면 더욱 최근 것 이여서 이전 것들을 상속합니다. 
 
그러나 한 가지 제가 강조하고 싶은 것은, 이 강의는 파이썬에 대한 강의는 아니라는 것입니다. 이상한 말이지요. 여러분은 그것을 사용하는 방법을 알아야 하지만 파이썬에서 세미 콜론이 어디 있어야 하는지 자세한 사항에 대한 것은 아닙니다. 알겠죠? 생각하기 위해 사용하는 것에 대한 것입니다. 
 
그리고 이 강의에서 여러분이 가져가야 할 것은 레시피를 설계하는 방법, 레시피를 구조하는 방법, 파이썬에서 그것들을 하는 방법을 배우는 것입니다. 같은 도구들은 쉽게 다른 언어로 변환됩니다. 여러분이 파이썬을 하는 방법을 알게 되면, 여러분은 일주일 혹은 몇 주 안에 다른 언어를 고를 수 있습니다. 
 
좋아요. 파이썬과 언어들에 대해 이야기하기 위해, 저는 우리가 여기서 하는 것을 위한 단계를 세우는 마지막 한 가지 것을 하고 싶군요. 그리고 그것은 언어의 다른 차원들에 대해 이야기 합니다. 그리고 제가 다루고자 하는 세 가지가 있습니다.  
 
첫 번째는, 이것이 고 수준인지 저 수준인지 입니다. 그것이 기본적으로 말하는 것은, 여러분은 기계의 내부와 얼마나 가깝습니까? 우리가 어셈블리 프로그래밍이라고 부르는 저 수준 언어에서는, 여러분의 초기 명령들은 매우 간단한 연산을 통해 문자 그대로 데이터들을 메모리의 한 영역에서 다른 영역으로 움직이는 것입니다. 고 수준 언어는, 설계자가 초기 명령들을 더 많이 만듭니다. 고 수준 언어에서, 제곱근은 단지 여러분이 사용할 수 있는 초기 명령이 될 것입니다. 여러분이 검토해서 코드를 짜기보다는요. 그리고 둘 사이에는 균형이 있습니다. 
 
두 번째 차원은, 이것이 일반적인 언어인지 무엇을 목표로 하는 언어인지 입니다. 제가 의미하는 것은, 초기 명령 세트들이 넓은 범위의 응용 프로그램들을 지원해 줍니까, 아니면 아주 특정한 응용 프로그램들 만을 목표로 합니까? MATLAB은 기본적으로 목표를 가지는 언어입니다. 그것은 행렬과 벡터와 같은 것을 대상으로 합니다. 
 
그리고 제가 지적하고 싶은 세 번째는 이것이 인터프리티드 언어인지 컴파일드 언어인지 입니다. 기본적으로 말하는 것은 다음과 같습니다: 인터프리티드 언어에서, 여러분이 쓰는 소스 코드라는 것을 가지는데, 이것은 간단한 검사기를 거치지만 기본적으로 인터프리터로 갑니다. 그것은 기계 내부에 있는 것으로 명령의 각 하나를 거치는 흐름을 제어합니다. 그리고 여러분에게 출력을 줍니다. 그래서 인터프리터는 런타임 때 여러분의 코드를 바로 간단하게 연산하는 것입니다.  
 
컴파일드 언어에서, 여러분은 중간 단계를 가집니다. 여러분이 소스 코드가 있으면, 그것은 검사기 또는 컴파일러 또는 둘 다를 거칩니다. 그리고 오브젝트 코드를 만들어 냅니다. 그리고 그것은 두 가지를 합니다: 하나는, 여러분의 코드에서 버그를 잡는 것을 돕습니다, 그리고 두 번째로 여러분이 실제로 런하기 전에 종종 그것을 명령의 더욱 효과적인 단계로 변환합니다. 알겠죠?  
 
그리고 둘 사이에는 균형이 있습니다. 인터프리티드 언어는 종종 디버그 하기가 더 쉽습니다. 왜냐하면 여러분은 여러분의 코드 그대로를 볼 수 있기 때문 입니다. 그러나 항상 빠르지는 않습니다. 컴파일드 언어는 보통 실행에 관해서는 더 빠릅니다. 그리고 그것은 여러분이 균형을 맞추고 싶은 것 중의 하나 입니다. 
 
좋아요. 파이썬의 경우는, 고 수준 언어입니다. 제 생각에는, 존도 저와 동의할 거라고 생각하는데, 파이썬은 기본적으로 일반적인 목적의 언어입니다. 예를 들어, 그것은 숫자 보다 문자열을 조작하는데 더욱 적합합니다. 그러나 정말 일반적인 목적의 언어입니다. 그리고 주로 – 제가 주로라고 말하면 안되지만, 그것은 인터프리티드 언어입니다. 알겠죠?  
 
결과적으로, 디버그를 돕는 데는 좋지 않습니다. 그러나 여러분이 – 미안해요, 잘 못 말했군요 – 그것은 여러분이 런하기 전에 무엇을 잡는 데는 좋지 않지만, 여러분이 날 때, 어떤 때는 디버깅이 쉽습니다.  
 
좋아요. 파이썬이 어떤 것 같나요? 파이썬에 대해 말하기 위해 – 사실, 저는 이런 방법으로 하고 싶었어요 – 우리는 파이썬에서 쓰는 방법에 대해 이야기 해 봐야 합니다. 다시 말해, 여러분은 제가 약간 돌아 와서 단계를 세우도록 해야 합니다. 
 
우리의 목표는 레시피들을 만드는 것입니다. 여러분은 모두 여러분이 여기 있을 때까지 훌륭한 요리사일 것입니다. 알겠죠? 우리의 목표는 문제를 가지고 그것을 이 컴퓨터적인 단계, 그 과정을 캡쳐하도록 하는 명령들의 순서로 만드는 것입니다. 
 
그렇게 하기 위해서, 우리는 서술해야 합니다: 초기 명령들이 무엇인지 뿐만 아니라, 우리는 그 언어에서 어떻게 합법적으로 캡쳐하고 컴퓨터와 상호 작용 합니까? 그리고 그것을 위해, 우리는 언어가 필요합니다. 우리는 언어의 요소에 대해 막 이야기 하려고 하던 참입니다. 그렇게 하기 위해서, 우리는 또한 하나의 마지막 차이점을 분리해야 합니다. 자연 언어와 같이, 우리는 문법과 의미를 분리해야 합니다.  
 
문법은 무엇입니까? 문법이 기본적으로 말하는, 이 언어에서 합법적인 표현은 무엇입니까? 여러분, 제 글씨가 형편 없죠? 영어 단어의 순서가 있습니다. 이것은 문법적으로 맞지 않습니다, 그렇죠? 이것은 문장이 아닙니다. 여기서는 동사가 없고, 명사의 순서만 있습니다. 같은 일이 우리의 언어에서도 있습니다. 우리는 여러분이 문법적으로 맞는 표현들을 합치는 방법을 서술해야 합니다. 알겠죠? 그리고 우리가 언어에 구조체를 더함으로써, 우리는 이야기해 갈 것입니다. 
 
우리가 해 가면서 두 번째로 매우 간단히 이야기 하고 싶은 것은 언어의 의미입니다. 그리고 여기 두 부분으로 나눠 볼 것입니다; 고정된 의미와 완전한 의미입니다. 고정된 의미는 기본적으로 어느 프로그램이 의미 있는가를 말합니다. 어떤 표현이 말이 되는지를요. 여기 영어 문장이 있습니다. 이것은 문법적으로 옳습니다. 그렇죠? 명사, 구, 동사, 명사구 입니다. 저는 이것이 의미 있는지 확인하지 못합니다. 여러분이 여러분의 가구에 개인적인 이름을 붙여주는 습관이 없으면요.  
 
요점이 무엇입니까? 다시 말해, 여러분은 문법적으로 맞지만 의미적으로 볼 때 의미 없는 것을 가질 수 있습니다. 그리고 고정된 의미는 우리가 표현이 무엇인지, 어떤 코드가 실제로 그것에 진짜 의미를 가지는지 결정하는 것을 돕는 방법이 될 것입니다. 알겠죠? 
 
그것의 마지막 부분은, 고정된 의미에 덧붙여서, 우리는 완전한 의미를 가집니다. 프로그램이 의미하는 것은 무엇입니까? 또는, 다른 방법으로 말해, 제가 그것을 런할 때 무슨 일이 일어납니까? 그것이 표현의 의미입니다. 그것이 여러분이 원하는 것입니다. 알겠죠? 여러분은 코드의 의미가 무엇인지 알고 싶죠? 제가 런할 때, 무슨 일이 일어 납니까? 그것이 제가 만들려고 하는 것입니다.  
 
이것을 꺼내는 이유는, 여러분이 볼 것은, 대부분의 언어와 특히 파이썬에서, -- 우리는 여기 많은 도움이 있습니다 – 좋아요, 파이썬은 여러분의 고정된 것, 미안해요, 여러분의 문법을 검사하는 것에 고정되어 있습니다. 그리고 사실, 부가적으로, 여러분이 문제 세트에서 문법적으로 맞지 않는 것을 제출하면, 여러분의 문법을 검사하는 작은 버튼이 있을 겁니다. 여러분이 문법적으로 맞지 않는 프로그램을 제출하면, 조교는 여러분에게 0점을 줄 것입니다. 왜냐하면 여러분이 문법이 맞는지 확인할 시간도 들이지 않았기 때문입니다. 시스템은 여러분이 그것을 찾도록 도와줄 것입니다. 파이썬에서, 그것을 찾을 것입니다. 저는 한 번에 하나의 버그를 생각합니다, 그렇죠 존? 그것은 한 번에 하나의 문법 에러를 찾습니다. 그래서 그것을 하려면 인내심이 조금 필요할 것입니다. 그렇지만 여러분은 문법이 맞는지 검사할 수 있습니다.  
 
여러분은 고정된 의미에서 여기 우리가 도움을 가지고 있다는 것을 볼 것입니다, 그리고 저는 곧 예를 들어 보겠습니다, 그 시스템을 의미하는데, 어떤 언어들은 그것에 다른 언어들 보다 좋습니다, 그러나 그것은 여러분이 문법적으로 고정적으로 맞지 않는 것을 찾도록 도와줍니다. 파이썬의 경우에, 저는 모두 런타임에서 생각합니다. 저는 여러분에게 다시 보여줄 것입니다, 존, 미리 검사하는 것이 없나요, 네? 
 
JOHN GUTTAG 교수: [안 들림] 
 
ERIC GRIMSON 교수: 네. 제가 생각하기에 대부분은 주로 런타임 때 잡힙니다. 그리고 여러분이 그것을 코드를 런할 때 까지 보지 않기 때문에 약간 고통스럽습니다. 그리고 사실 우리는 곧 예를 볼 것입니다. 여러분이 찾지만, 여러분은 거기서 도움이 필요합니다. 
 
문제는 여러분이 여기서 찾는 것은 가장 덜 걱정스러운 버그들이라는 것입니다. 그것들은 찾아 내기 쉽습니다. 그것들이 거기 있으면 프로그램을 런할 수 없습니다. 그래서 여러분은 이상한 답을 얻을 수 없습니다. 모든 것이 고정된 의미 검사에서 잡히는 것은 아닙니다. 몇 가지는 넘어 가서, 사실 귀찮게 합니다. 이것이 문제입니다. 여러분의 프로그램은 여러분에게 여전히 가치 있지만, 여러분이 의도한 것은 아닐 수도 있습니다. 그리고 여러분은 항상 알려주지 않습니다. 그것이 어떤 파멸의 실패를 초래 하기 전에 다른 computation의 전체를 통해 그것의 방법을 전파 시킬 수 있습니다. 그래서 사실, 고정된 의미의 문제는 여러분이 그것이 모든 것을 잡기를 원한다는 것입니다. 여러분은 항상 그것을 얻지 못합니다. 슬프게도 우리는 여기 많은 도움이 없습니다. 우리는 어디서 그것을 하고 싶은가요. 그러나 그것은 여러분의 일입니다.  
 
좋아요. 여러분이 문법적으로 맞고, 옳은 고정된 의미를 가지고 있는 것이 있으면 무슨 일이 일어 나나요? 여러분이 그것을 런합니까? 그것은 런할 수 있고 여러분에게 옳은 답을 줍니다. 그것은 고장 나서 영원히 루프를 돌 것입니다. 런해서 여러분에게 명백히 옳은 답을 줄 것입니다. 그리고 여러분은 항상 말할 수 있기 않을 것입니다. 자, 여러분은 여러분에게 매우 자주 도움이 되지 않는 고장이 언제 나는지 압니다. 그러나 여러분은 무한 루프에서 무엇이 막혔는지 또는 단지 계산하는데 오랜 시간이 걸리는지 항상 말할 수 없습니다. 여러분은 여러분을 위한 그 장소의 시스템을 갖고 싶지만, 그것은 가능하지 않습니다.  
 
그리고 이 마지막 것을 다루기 위해서, 여러분은 스타일을 발전시켜야 합니다. 알겠죠? 우리는 여러분이 좋은 프로그래밍 스타일을 발전시키는 방법을 돕도록 할 것입니다. 그러나 여러분은 발생하는 의미적인 버그를 유발하는 장소가 여러분에게 쉬울 것이라는 방식으로 쓸 필요가 있습니다.  
 
좋아요. 정말 긴 서두처럼 들리겠지만, 그렇습니다. 파이썬을 시작해 봅시다. 그러나 다시, 제 목표는 여러분이 computation이 무엇인지, 우리가 왜 그것을 하는지를 알게 하는 것입니다. 저는 여러분에게 나중에 다시 상기시켜 줄 것입니다. 우리의 목표는 우리가 복잡한 표현식을 결합하는 초기 명령들의 세트를 가지는 것입니다. 그러면 우리는 초기 명령들에서 끌어서 쓸 수 있고 새로운 정보를 추론하기 위해, 이 제어의 흐름에서 명령들의 순서를 사용할 수 있습니다. 이것이 우리가 저기서 말했던 명령하는 지식입니다. 그래서 저는 오늘 시작할 것입니다. 우리는 약 5분 10분 정도 남았군요 – 미안해요, 5분 남았군요 – 파이썬을 시작하기 위해, 우리는 다음 번에, 이것을 명백히 알아야 합니다. 파이썬의 간단한 부분들입니다. 
 
어떤 표현식을 만들어내기 위해, 우리는 변수들이 필요합니다. 초기 데이터 요소입니다. 그리고 파이썬에서, 우리는 시작할 두 가지가 있습니다; 숫자들이 있고, 문자열이 있습니다. 숫자는 여러분이 예상하는 것입니다. 숫자가 있습니다. 다른 숫자가 있습니다. 알겠죠? 문자열은 파이썬에서 여는 따옴표와 닫는 따옴표에 따라 오는 문자들의 순서로 캡쳐 됩니다.  
 
타입은 파이썬에서 모든 데이터 타입과 연관됩니다. 그것은 어떤 것이 무엇인지 식별해 줍니다. 이것들 중 몇 가지는 명백합니다. 문자열은 스스로의 타입입니다. 그러나 숫자들은, 예를 들어, 우리는 많은 타입을 가집니다. 이것은 우리가 인티져 또는 INT라고 부르는 것입니다. 그리고 이것은 소수점 또는 float 라고 부르는 것입니다. 또는 이것을 실수라고 생각해 보세요. 그리고 우리가 볼 수 있는 다른 것들도 있습니다. 
 
우리는 분류 체계를 구축할 것입니다. 그러나 적절한 이유는 각 타입과 연관 되어 있습니다. 그것은 그들의 일을 하기 위한 특정한 입력 타입을 기대하는 연산자들의 세트입니다. 그리고 주어진 입력 타입에서, 출력을 다시 가질 것입니다. 
 
좋아요. 이것을 다루기 위해, 여러분에게 예를 보여주겠습니다. 그리고 저는 그것이 올라 가길 바랍니다, 좋아요. 제가 여기서 가지고 있는 것은 파이썬 쉘입니다. 그리고 저는 여러분에게 우리가 표현식 만드는 것을 시작하는 방법의 간단한 예를 보여주겠습니다. 그리고 이것은 여러분이 내일 할 것 뿐 만 아니라 다음 시간에 볼 것입니다. 그래요. 쉘부터 시작합시다. 저는 표현식에서 타입을 알아낼 수 있습니다. 
 
사실, 돌아 가서 비디오에서 이것을 다시 해봅시다. 저는 숫자에서 타입을 알 수 있고 다시 숫자를 얻습니다. 문자열의 타입을 알고 다시 문자열을 얻습니다. 그런데, 문자열은 그들 안에 공간을 가지고 있습니다. 그들은 다른 특징을 가지고 있습니다. 그것은 그것의 순서입니다. 그런데, 문자열 5를 주목하세요 – 미안해요, 스트링의 숫자 5 숫자 2는 숫자 52와 다릅니다. 그 차이를 알기 위해 따옴표가 있습니다. 우리는 왜 그런지 곧 알게 됩니다. 
 
그런데 제가 여기서 하려는 것은 표현식에서 인터프리터로 타입을 알려주는 것입니다. 그것은 변수를 추론하고 그것을 출력하기 위해 규칙을 사용합니다. 제가 여기서 하려는 것은, 저는 이것들의 결합을 하려고 합니다. 그래서 우리는 간단한 것, 연산들과 관련됩니다. 그래서 숫자에서, 우리는 여러분이 예상한 것, 산수를 가지고 있습니다. 여러분에게 그 예를 보여주겠습니다.  
 
그리고 사실, 저는 여기서 하나의 다른 차이를 하려고 합니다. 제가 하는 것은 – 자, 이런 식으로 시작합시다 – 여기 표현식이 있습니다. 그리고 파이썬에서 표현식은 피연산자, 연산자, 피연산자입니다. 우리가 이와 같은 간단한 표현식을 할 때요. 그리고 제가 이것을 인터프리터에 주면, 그것은 저에게 어떤 변수인지 정확히 제가 예상하는 것을 돌려줍니다. 알겠죠? 
 
제가 만드는 차이는 표현식입니다. 인터프리터는 그것의 변수를 가져옵니다. 우리가 코드를 만들 때, 우리는 명령어를 사용할 것입니다. 또는 서술문을요. 실제 변수를 가지는 것이 무엇인지 컴퓨터에게 물어보세요. 그래서 저는 이것을 비슷하게 할 수 있습니다. 그것은 이상하게 보일 것입니다. 왜냐하면 그것은 저에게 같은 변수를 돌려주니까요. 그러나 그것은 사실 약간 다른 것입니다. 
 
그런데 주목하세요. 언제 그것이 다른 색으로 나타나는 타입을 알 수 있습니까? 그것은 파이썬이 말합니다. 그것은 명령문입니다. 그것은 표현식의 변수를 얻고 그것을 다시 출력해 주는 특정한 명령문입니다. 우리가 코드 쓰는 것을 시작할 때, 여러분은 그 차이를 알 수 있을 것입니다. 그러나 지금은, 그것에 대해 걱정하지 마세요, 저는 단지 그 생각을 심어 주고 싶었습니다. 
 
좋아요. 우리가 한번 그것을 얻으면, 우리는 확실히 이와 같은 것을 할 수 있습니다. 그 주변의 따옴표에 주목하세요. 그리고 그것을 문자열로 다루세요. 그것은 저에게 그 변수 보다는 52 곱하기 7이라는 그 문자열 값을 가져다 줍니다. 이제, 우리가 그것을 얻으면, 우리는 그것을 시작할 수 있습니다. 그리고 여기 프린트를 사용할 것입니다. – 제가 타입을 알면, 그것을 시작하기 위해, 타입을 알 수 없습니다, 여기 해 봅시다 – 습관을 시작하기 위해서요. 저는 문자열을 찍어낼 수 있습니다. 저는 찍어낼 수 있어요 – 아! – 여기에 내 것 중 하나를 잡는 것의 첫 번째 예가 있습니다. 이것은 고정된 의미 에러입니다. 
 
그래서 여기서 어떻게 되고 있죠? 저는 그것에 저기에 있는 연산자를 가지는 표현식을 주었습니다. 그것은 연산 타입입니다. 그러나 저는 두 문자열을 주었습니다. 그리고 그것은 저에게 불평하며 말합니다. 당신은 그것을 할 수 없다고. 저는 두 문자열을 어떻게 가져와서 그들을 함께 곱하는지 모릅니다. 불행히도 – 이제 존은 이것에 저와 동의하지 않을 것입니다 – 그러나, 불행히도 파이썬에서 여러분은 이와 같은 것을 할 수 있습니다. 여러분은 무엇을 알아냈습니까? 문법에 맞는 것을 보았습니까? 문자열은 세 번이고 숫자 3입니까? 자 이것은 저에게 3 3개를 연이어 주었습니다.  
 
저는 이것을 싫어합니다. 미안해요, 존, 저는 이것을 싫어해요. 이것이 그 곱셈 연한자를 두 개의 다른 일로 오버로딩 하기 때문입니다. 여러분이 저에게 두 수를 주면, 저는 옳게 할 것입니다. 여러분이 저에게 숫자 하나와 문자열 하나를 주면, 저는 이것을 같이 연관시킬 것입니다. 이것은 매우 다른 연산입니다. 그렇지만, 이것은 그것이 하는 것입니다. 
 
학생: [안 들림] 
 
ERIC GRIMSON 교수: 네. 여러분이 알다시피, 조금 나중에 반박의 문구가 있을 것입니다. 정치적인 논쟁처럼요. 그리고 그는 그것을 특징으로써 좋아합니다. 저는 그것을 싫어합니다. 여러분은 그가 Lisp 프로그래머가 아니고 저는 그렇다고 말할 수 있어요. 
 
좋아요. 저는 몇 가지 더욱 바른 예제들을 하고 싶습니다. 여기 다른 한 가지가 있습니다. 아하! 여러분에게 문법 오류의 예를 주겠습니다. 52A는 말이 되지 않습니다. 그리고 여러분은, 잠시만요, 그것이 문자열이 아니라고 말할 것입니다. 그리고 답변은 아니오 입니다. 저는 그것에 따옴표를 하면 문자열이라고 말한 적이 없습니다. 그리고 기계가 그것에 어떻게 다르게 반응하는지 주목하세요. 이 경우에, 이것은 문법 에러입니다. 그리고 그것이 어디에서 와서 제가 어디로 돌아 가서 고치는지 강조하고 있습니다.  
 
좋아요. 몇 가지 다른 예를 들어 봅시다. 네? 저는 곱셈을 할 수 있습니다. 저는 이것을 이미 보았습니다. 저는 덧셈을 할 수 있습니다. 3 더하기 5. 저는 무언가에 힘을 줄 수 있고, 더블 스타, 3을 5번 곱합니다. 저는 나누기를 할 수 있습니다, 그렇죠? 후아. 맞죠? 3 나누기 5는 0입니까? 아마 부시의 경제 속에 있겐군요 – 아닙니다, 전 오늘 어떤 정치적인 말은 하지 않을 것입니다, 알겠죠? 
 
무슨 일이 일어났습니까? 이것은 여러분이 조심해야 하는 곳 중 하나 입니다. 이것은 인티져 부분을 하고 있습니다. 그래서, 3 나누기 5는 0이고, 나머지는 3입니다. 그래서 이것은 옳은 답입니다. 완전한 값을 얻고 싶으면, float로 해야 합니다. 그리고 네, 여러분은 그것을 보고 말할 수 있습니다. 그것은 맞는 것입니까? 자, 정확도의 정도에 따라, 네, 그것은 0.6 이 나올 것입니다.  
 
좋아요. 저는 다른 것을 할 수 있습니다. 특별히, 저는 문자열에서 비슷한 연산을 할 수 있습니다. 좋아요, 저는 확실히 문자열을 찍어 낼 수 있습니다. 그러나 저는 사실 문자열들을 같이 더할 수 있습니다. 그리고 여러분이 보았듯이, 저는 문자열을 곱할 수 있습니다. 여러분은 이것이 무엇을 하는 것인지 추측할 수 있습니다. 이것은 그것들을 하나로 합치는 것입니다. 저는 – 여러분이 천천히 하도록 합니다, 마지막 예제 하나를 해보겠습니다. 저는 또한 그것들을 저장할 변수들을 원합니다. 그리고 그것을 하기 위해, 제가 변수를 가지면, 제가 그것을 가지고, 그것을 하기 위해, 저는 이와 같은 것을 할 수 있습니다.  
 
그 문장이 무엇을 하는 건가요? 그것은 변수의 이름을 만드는 것입니다 – 제가 저기서 했던 것이죠, 사실, 그것에 타입을 붙여 보겠습니다 – mystring, 등호 표시로, 이것은 배정하여 그 이름으로 묶는 것입니다. 다음 식의 변수로요. 결과적으로, 저는 이제 그것의 이름을 부를 수 있습니다. 제가 mystring의 값을 가지면, 또는 제가 말하면, mystring을 가지고 mylastname 문자열에 더합니다, 그리고 찍어냅니다. 
 
그래서 이것이 첫 번째 시작이었습니다. 우리가 무엇을 했나요? 우리는 변수, 숫자, 문자열을 했습니다. 우리는 이것들과 연관 된 연산들을 했습니다. 저는 여기 몇 가지를 만들어 냈습니다. 여러분은 그것들을 탐험할 기회를 가지게 될 것입니다. 그러면 여러분은 문자열을 위한 표준의 수뿐 만 아니라 길이나 더하기 또는 여러분이 그것들로 할 수 있는 다른 것들을 알게 될 것입니다. 그리고 제가 변수를 가지면, 저는 그것들을 가지고 그것들에 이름을 줄 수 있습니다. 그리고 그것은 제가 경계를 지었을 때 한 것입니다. 묶여진 mystring 이름을 사용하세요. 또는 Eric의 값을 가지세요, 그래서 저는 제가 사용하고 싶은 것을 어디에든 그것을 언급할 수 있습니다.  
 
시간을 차지해서 미안해요, 우리는 다음 시간에 다시 올 것입니다, 웹 사이트에 가서 내일 설명을 위해 등록하세요. 
 
* MIT OCW 강의들은 SNOW에 의해서 번역되고 있습니다. MIT대학, MIT대학의 교수진들 및 MIT OCW는 SNOW가 번역한 스크립트를 검토하거나 승인하는 일과는 관계가 없습니다. MIT대학 및 MIT OCW는 SNOW의 번역물에 관련한 보증은 없으며, 상품성에 대한 보증과 특수한 목적, 사용 또는 적용을 위한 적합성 보증 및 모든 다른 의무와 책임을 포함하되 그에 제한되지 않고, 모든 다른 명시적 또는 묵시적 보증을 대체하고 배제합니다. MIT OCW는 번역 오류에 대해 어떠한 책임도 없으며 번역의 부정확함에 따른 어떠한 오류나 결함은 전적으로 MIT OCW가 아닌 SNOW에게 책임이 있다는 것을 명시하는 바입니다. (These MIT OpenCourseWare course materials have been translated into Korean by SNOW. The MIT faculty authors, MIT, or MIT OpenCourseWare have not reviewed or approved these translations, and MIT and MIT OpenCourseWare makes no representations or warranties of any kind concerning the translated materials, express or implied, including, without limitation, warranties of merchantability, fitness for a particular purpose, non-infringement, or the absence of errors, whether or not discoverable. MIT OpenCourseWare bears no responsibility for any inaccuracies in translation. Any inaccuracies or other defects contained in this material, due to inaccuracies in language translation, are the sole responsibility of SNOW and not MIT OpenCourseWare.)
펼쳐보기

히스토리

프린트

*  
님이 등록 해 주셨습니다.
The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseware continue to offer high-quality educational resources for free. To make a donation, or view additional materials from hundreds of MIT courses, visit MIT OpenCourseware, at ocw.mit.edu. 
 
PROFESSOR: Good morning. Try it again. Good morning. 
 
STUDENTS: Good morning. 
 
PROFESSOR: Thank you. This is 6.00, also known as Introduction to Computer Science and Programming. My name is Eric Grimson, I have together Professor John Guttag over here, we're going to be lecturing the course this term. I want to give you a heads up; you're getting some serious firepower this term. John was department head for ten years, felt like a century, and in course six, I'm the current department head in course six. John's been lecturing for thirty years, roughly. All right, I'm the young guy, I've only been lecturing for twenty-five years. You can tell, I have less grey hair than he does. What I'm trying to say to you is, we take this course really seriously. We hope you do as well. But we think it's really important for the department to help everybody learn about computation, and that's what this course is about. 
 
What I want to do today is three things: I'm going to start-- actually, I shouldn't say start, I'm going to do a little bit of administrivia, the kinds of things you need to know about how we're going to run the course. I want to talk about the goal of the course, what it is you'll be able to do at the end of this course when you get through it, and then I want to begin talking about the concepts and tools of computational thinking, which is what we're primarily going to focus on here. We're going to try and help you learn how to think like a computer scientist, and we're going to begin talking about that towards the end of this lecture and of course throughout the rest of the lectures that carry on. 
 
Right, let's start with the goals. I'm going to give you goals in two levels. The strategic goals are the following: we want to help prepare freshmen and sophomores who are interested in majoring in course six to get an easy entry into the department, especially for those students who don't have a lot of prior programming experience. If you're in that category, don't panic, you're going to get it. We're going to help you ramp in and you'll certainly be able to start the course six curriculum and do just fine and still finish on target. We don't expect everybody to be a course six major, contrary to popular opinion, so for those are you not in that category, the second thing we want to do is we want to help students who don't plan to major in course six to feel justifiably confident in their ability to write and read small pieces of code. 
 
For all students, what we want to do is we want to give you an understanding of the role computation can and cannot play in tackling technical problems. So that you will come away with a sense of what you can do, what you can't do, and what kinds of things you should use to tackle complex problems. 
 
And finally, we want to position all students so that you can easily, if you like, compete for things like your office and summer jobs. Because you'll have an appropriate level of confidence and competence in your ability to do computational problem solving. Those are the strategic goals. 
 
Now, this course is primarily aimed at students who have little or no prior programming experience. As a consequence, we believe that no student here is under-qualified for this course: you're all MIT students, you're all qualified to be here. But we also hope that there aren't any students here who are over-qualified for this course. And what do I mean by that? If you've done a lot prior programming, this is probably not the best course for you, and if you're in that category, I would please encourage you to talk to John or I after class about what your goals are, what kind of experience you have, and how we might find you a course that better meets your goals. 
 
Second reason we don't want over-qualified students in the class, it sounds a little nasty, but the second reason is, an over-qualified student, somebody who's, I don't know, programmed for Google for the last five years, is going to have an easy time in this course, but we don't want such a student accidentally intimidating the rest of you. We don't want you to feel inadequate when you're simply inexperienced. And so, it really is a course aimed at students with little or no prior programming experience. And again, if you're not in that category, talk to John or I after class, and we'll help you figure out where you might want to go. 
 
OK. Those are the top-level goals of the course. Let's talk sort of at a more tactical level, about what do we want you to know in this course. What we want you to be able to do by the time you leave this course? So here are the skills that we would like you to acquire. Right, the first skill we want you to acquire, is we want you to be able to use the basic tools of computational thinking to write small scale programs. I'm going to keep coming back to that idea, but I'm going to call it computational thinking. And that's so you can write small pieces of code. And small is not derogatory here, by the way, it just says the size of things you're going to be able to do. 
 
Second skill we want you to have at the end of this course is the ability to use a vocabulary of computational tools in order to be able to understand programs written by others. So you're going to be able to write, you're going to be able to read. 
 
This latter skill, by the way, is incredibly valuable. Because you won't want to do everything from scratch yourself, you want to be able to look at what is being created by somebody else and understand what is inside of there, whether it works correctly and how you can build on it. This is one of the few places where plagiarism is an OK thing. It's not bad to, if you like, learn from the skills of others in order to create something you want to write. Although we'll come back to plagiarism as a bad thing later on. 
 
Third thing we want you to do, is to understand the fundamental both capabilities and limitations of computations, and the costs associated with them. And that latter statement sounds funny, you don't think of computations having limits, but they do. There're some things that cannot be computed. We want you to understand where those limits are. So you're going to be able to understand abilities and limits. 
 
And then, finally, the last tactical skill that you're going to get out of this course is you're going to have the ability to map scientific problems into a computational frame. So you're going to be able to take a description of a problem and map it into something computational. 
 
Now if you think about it, boy, it sounds like grammar school. We're going to teach you to read, we're going to teach you to write, we're going to teach you to understand what you can and cannot do, and most importantly, we're going to try and give you the start of an ability to take a description of a problem from some other domain, and figure out how to map it into that domain of computation so you can do the reading and writing that you want to do. 
 
OK, in a few minutes we're going to start talking then about what is computation, how are we going to start building those tools, but that's what you should take away, that's what you're going to gain out of this course by the time you're done. 
 
Now, let me take a sidebar for about five minutes to talk about course administration, the administrivia, things that we're going to do in the course, just so you know what the rules are. Right, so, class is two hours of lecture a week. You obviously know where and you know when, because you're here. Tuesdays and Thursdays at 11:00. One hour of recitation a week, on Fridays, and we'll come back in a second to how you're going to get set up for that. And nine hours a week of outside-the-class work. Those nine hours are going to be primarily working on problem sets, and all the problems sets are going to involve programming in Python, which is the language we're going to be using this term. 
 
Now, one of the things you're going to see is the first problem sets are pretty easy. Actually, that's probably wrong, John, right? They're very easy. And we're going to ramp up. By the time you get to the end of the term, you're going to be dealing with some fairly complex things, so one of the things you're going to see is, we're going to make heavy use of libraries, or code written by others. It'll allow you to tackle interesting problems I'll have you to write from scratch, but it does mean that this skill here is going to be really valuable. You need to be able to read that code and understand it, as well as write your own. 
 
OK. Two quizzes. During the term, the dates have already been scheduled. John, I forgot to look them up, I think it's October 2nd and November 4th, it'll be on the course website. My point is, go check the course website, which by the way is right there. If you have, if you know you have a conflict with one of those quiz dates now, please see John or I right away. We'll arrange something ahead of time. But if you-- The reason I'm saying that is, you know, you know that you're getting married that day for example, we will excuse you from the quiz to get married. We'll expect you come right back to do the quiz by the way, but the-- Boy, tough crowd. All right. If you have a conflict, please let us know. 
 
Second thing is, if you have an MIT documented special need for taking quizzes, please see John or I well in advance. At least two weeks before the quiz. Again, we'll arrange for this, but you need to give us enough warning so that we can deal with that. 
 
OK, the quizzes are open book. This course is not about memory. It's not how well you can memorize facts: in fact, I think both John and I are a little sensitive to memory tests, given our age, right John? This is not about how you memorize things, it's about how you think. So they're open note, open book. It's really going to test your ability to think. 
 
The grades for the course will be assigned roughly, and I use the word roughly because we reserve the right to move these numbers around a little bit, but basically in the following percentages: 55% of your grade comes from the problem sets, the other 45% come from the quizzes. And I should've said there's two quizzes and a final exam. I forgot, that final exam during final period. So the quiz percentages are 10%, 15%, and 20%. Which makes up the other 45%. 
 
OK. Other administrivia. Let me just look through my list here. First problem set, problem set zero, has already been posted. This is a really easy one. We intend it to be a really easy problem set. It's basically to get you to load up Python on your machine and make sure you understand how to interact with it. 
 
The first problem set will be posted shortly, it's also pretty boring-- somewhat like my lectures but not John's-- and that means, you know, we want you just to get going on things. Don't worry, we're going to make them more interesting as you go along. 
 
Nonetheless, I want to stress that none of these problems sets are intended to be lethal. We're not using them to weed you out, we're using them to help you learn. So if you run into a problem set that just, you don't get, all right? Seek help. Could be psychiatric help, could be a TA. I recommend the TA. My point being, please come and talk to somebody. The problems are set up so that, if you start down the right path, it should be pretty straight-forward to work it through. If you start down a plausible but incorrect path, you can sometimes find yourself stuck in the weeds somewhere, and we want to bring you back in. So part of the goal here is, this should not be a grueling, exhausting kind of task, it's really something that should be helping you learn the material. If you need help, ask John, myself, or the TAs. That's what we're here for. 
 
OK. We're going to run primarily a paperless subject, that's why the website is there. Please check it, that's where everything's going to be posted in terms of things you need to know. In particular, please go to it today, you will find a form there that you need to fill out to register for, or sign up for rather, a recitation. 
 
Recitations are on Friday. Right now, we have them scheduled at 9:00, 10:00, 11:00, 12:00, 1:00, and 2:00. We may drop one of the recitations, just depending on course size, all right? So we reserve the right, unfortunately, to have to move you around. My guess is that 9:00 is not going to be a tremendously popular time, but maybe you'll surprise me. Nonetheless, please go in and sign up. We will let you sign up for whichever recitation makes sense for you. Again, we reserve the right to move people around if we have to, just to balance load, but we want you to find something that fits your schedule rather than ours. 
 
OK. Other things. There is no required text. If you feel exposed without a text book, you really have to have a textbook, you'll find one recommended-- actually I'm going to reuse that word, John, at least suggest it, on the course website. I don't think either of us are thrilled with the text, it's the best we've probably found for Python, it's OK. If you need it, it's there. But we're going to basically not rely on any specific text. 
 
Right. Related to that: attendance here is obviously not mandatory. You ain't in high school anymore. I think both of us would love to see your smiling faces, or at least your faces, even if you're not smiling at us every day. Point I want to make about this, though, is that we are going to cover a lot of material that is not in the assigned readings, and we do have assigned readings associated with each one of these lectures. If you choose not to show up today-- or sorry, you did choose to show up today, if you choose not to show up in future days-- we'll understand, but please also understand that the TAs won't have a lot of patience with you if you're asking a question about something that was either covered in the readings, or covered in the lecture and is pretty straight forward. All right? We expect you to behave responsibly and we will as well. All right. 
 
I think the last thing I want to say is, we will not be handing out class notes. Now this sounds like a draconian measure; let me tell you why. Every study I know of, and I suspect every one John knows, about learning, stresses that students learn best when they take notes. Ironically, even if they never look at them. OK. The process of writing is exercising both halves of your brain, and it's actually helping you learn, and so taking notes is really valuable thing. Therefore we're not going to distribute notes. What we will distribute for most lectures is a handout that's mostly code examples that we're going to do. I don't happen to have one today because we're not going to do a lot of code. We will in future. Those notes are going to make no sense, I'm guessing, outside of the lecture, all right? So it's not just, you can swing by 11:04 and grab a copy and go off and catch some more sleep. What we recommend is you use those notes to take your own annotations to help you understand what's going on, but we're not going to provide class notes. We want you to take your own notes to help you, if you like, spur your own learning process. 
 
All right. And then finally, I want to stress that John, myself, all of the staff, our job is to help you learn. That's what we're here for. It's what we get excited about. If you're stuck, if you're struggling, if you're not certain about something, please ask. We're not mind readers, we can't tell when you're struggling, other than sort of seeing the expression on your face, we need your help in identifying that. But all of the TAs, many of whom are sitting down in the front row over here, are here to help, so come and ask. At the same time, remember that they're students too. And if you come and ask a question that you could have easily answered by doing the reading, coming to lecture, or using Google, they're going to have less patience. But helping you understand things that really are a conceptual difficulty is what they're here for and what we're here for, so please come and talk to us. 
 
OK. That takes care of the administrivia preamble. John, things we add? 
 
PROFESSOR GUTTAG: Two more quick things. This semester, your class is being videotaped for OpenCourseware. If any of you don't want your image recorded and posted on the web, you're supposed to sit in the back three rows. 
 
PROFESSOR GRIMSON: Ah, thank you. I forgot. 
 
PROFESSOR GUTTAG: --Because the camera may pan. I think you're all very good-looking and give MIT a good image, so please, feel free to be filmed. 
 
PROFESSOR GRIMSON: I'll turn around, so if you want to, you know, move to the back, I won't see who moves. Right. Great. Thank you, John. 
 
PROFESSOR GUTTAG: So that, the other thing I want to mention is, recitations are also very important. We will be covering material in recitations that're not in the lectures, not in the reading, and we do expect you to attend recitations. 
 
PROFESSOR GRIMSON: Great. Thanks, John. Any questions about the administrivia? I know it's boring, but we need to do it so you know what the ground rules are. 
 
Good. OK. Let's talk about computation. As I said, our strategic goal, our tactical goals, are to help you think like a computer scientist. Another way of saying it is, we want to give you the skill so that you can make the computer do what you want it to do. And we hope that at the end of the class, every time you're confronted with some technical problem, one of your first instincts is going to be, "How do I write the piece of code that's going to help me solve that?" 
 
So we want to help you think like a computer scientist. All right. And that, is an interesting statement. What does it mean, to think like a computer scientist? Well, let's see. The primary knowledge you're going to take away from this course is this notion of computational problem solving, this ability to think in computational modes of thought. And unlike in a lot of introductory courses, as a consequence, having the ability to memorize is not going to help you. It's really learning those notions of the tools that you want to use. What in the world does it mean to say computational mode of thought? It sounds like a hifalutin phrase you use when you're trying to persuade a VC to fund you. Right. So to answer this, we really have to ask a different question, a related question; so, what's computation? 
 
It's like a strange statement, right? What is computation? And part of the reason for putting it up is that I want to, as much as possible, answer that question by separating out the mechanism, which is the computer, from computational thinking. Right. The artifact should not be what's driving this. It should be the notion of, "What does it mean to do computation?" 
 
Now, to answer that, I'm going to back up one more level. And I'm going to pose what sounds like a philosophy question, which is, "What is knowledge?" And you'll see in about two minutes why I'm going to do this. But I'm going to suggest that I can divide knowledge into at least two categories. OK, and what is knowledge? And the two categories I'm going to divide them into are declarative and imperative knowledge. 
 
Right. What in the world is declarative knowledge? Think of it as statements of fact. It's assertions of truth. Boy, in this political season, that's a really dangerous phrase to use, right? But it's a statement of fact. I'll stay away from the political comments. Let me give you an example of this. Right. Here's a declarative statement. The square root of x is that y such that y squared equals x, y's positive. You all know that. But what I want you to see here, is that's a statement of fact. It's a definition. It's an axiom. It doesn't help you find square roots. If I say x is 2, I want to know, what's the square root of 2, well if you're enough of a geek, you'll say 1.41529 or whatever the heck it is, but in general, this doesn't help you find the square root. The closest it does is it would let you test. You know, if you're wandering through Harvard Square and you see an out-of-work Harvard grad, they're handing out examples of square roots, they'll give you an example and you can test it to see, is the square root of 2, 1.41529 or whatever. I don't even get laughs at Harvard jokes, John, I'm going to stop in a second here, all right? All right, so what am I trying to say here? It doesn't -- yeah, exactly. We're staying away from that, really quickly, especially with the cameras rolling. 
 
All right. What am I trying to say? It tells you how you might test something but it doesn't tell you how to. 
 
And that's what imperative knowledge is. Imperative knowledge is a description of how to deduce something. So let me give you an example of a piece of imperative knowledge. All right, this is actually a very old piece of imperative knowledge for computing square roots, it's attributed to Heron of Alexandria, although I believe that the Babylonians are suspected of knowing it beforehand. But here is a piece of imperative knowledge. All right? I'm going to start with a guess, I'm going to call it g. And then I'm going to say, if g squared is close to x, stop. And return g. It's a good enough answer. Otherwise, I'm going to get a new guess by taking g, x over g, adding them, and dividing by two. Then you take the average of g and x over g. Don't worry about how came about, Heron found this out. But that gives me a new guess, and I'm going to repeat. 
 
That's a recipe. That's a description of a set of steps. Notice what it has, it has a bunch of nice things that we want to use, right? It's a sequence of specific instructions that I do in order. Along the way I have some tests, and depending on the value of that test, I may change where I am in that sequence of instructions. And it has an end test, something that tells me when I'm done and what the answer is. This tells you how to find square roots. it's how-to knowledge. It's imperative knowledge. 
 
All right. That's what computation basically is about. We want to have ways of capturing this process. OK, and that leads now to an interesting question, which would be, "How do I build a mechanical process to capture that set of computations?" So I'm going to suggest that there's an easy way to do it-- I realized I did the boards in the wrong order here-- one of the ways I could do it is, you could imagine building a little circuit to do this. If I had a couple of elements of stored values in it, I had some wires to move things around, I had a little thing to do addition, little thing to do division, and a something to do the testing, I could build a little circuit that would actually do this computation. 
 
OK. That, strange as it sounds, is actually an example of the earliest computers, because the earliest computers were what we call fixed-program computers, meaning that they had a piece of circuitry designed to do a specific computation. And that's what they would do: they would do that specific computation. You've seen these a lot, right? A good example of this: calculator. It's basically an example of a fixed-program computer. It does arithmetic. If you want play video games on it, good luck. If you want to do word processing on it, good luck. It's designed to do a specific thing. It's a fixed-program computer. 
 
In fact, a lot of the other really interesting early ones similarly have this flavor, to give an example: I never know how to pronounce this, Atanasoff, 1941. One of the earliest computational things was a thing designed by a guy named Atanasoff, and it basically solved linear equations. Handy thing to do if you're doing 1801, all right, or 1806, or whatever you want to do those things in. All it could do, though, was solve those equations. 
 
One of my favorite examples of an early computer was done by Alan Turing, one of the great computer scientists of all time, called the bombe, which was designed to break codes. It was actually used during WWII to break German Enigma codes. And what it was designed to do, was to solve that specific problem. 
 
The point I'm trying to make is, fixed-program computers is where we started, but it doesn't really get us to where we'd like to be. We want to capture this idea of problem solving. So let's see how we'd get there. So even within this framework of, given a description of a computation as a set of steps, in the idea that I could build a circuit to do it, let me suggest for you what would be a wonderful circuit to build. 
 
Suppose you could build a circuit with the following property: the input to this circuit would be any other circuit diagram. Give it a circuit diagram for some computation, you give it to the circuit, and that circuit would wonderfully reconfigure itself to act like the circuits diagram. Which would mean, it could act like a calculator. Or, it could act like Turing's bombe. Or, it could act like a square root machine. 
 
So what would that circuit look like? You can imagine these tiny little robots wandering around, right? Pulling wires and pulling out components and stacking them together. How would you build a circuit that could take a circuit diagram in and make a machine act like that circuit? Sounds like a neat challenge. 
 
Let me change the game slightly. Suppose instead, I want a machine that can take a recipe, the description of a sequence of steps, take that as its input, and then that machine will now act like what is described in that recipe. Reconfigure itself, emulate it, however you want to use the words, it's going to change how it does the computation. 
 
That would be cool. And that exists. It's called an interpreter. It is the basic heart of every computer. What it is doing, is saying, change the game. This is now an example of a stored-program computer. What that means, in a stored-program computer, is that I can provide to the computer a sequence of instructions describing the process I want it to execute. And inside of the machine, and things we'll talk about, there is a process that will allow that sequence to be executed as described in that recipe, so it can behave like any thing that I can describe in one of those recipes. 
 
All right. That actually seems like a really nice thing to have, and so let me show you what that would basically look like. Inside of a stored-program computer, we would have the following: we have a memory, it's connected to two things; control unit, in what's called an ALU, an arithmetic logic unit, and this can take in input, and spit out output, and inside this stored-program computer, excuse me, you have the following: you have a sequence of instructions. And these all get stored in there. Notice the difference. The recipe, the sequence of instructions, is actually getting read in, and it's treated just like data. It's inside the memory of the machine, which means we have access to it, we can change it, we can use it to build new pieces of code, as well as we can interpret it. One other piece that goes into this computer-- I never remember where to put the PC, John, control? ALU? Separate? I'll put it separate-- you have a thing called a program counter. 
 
And here's the basis of the computation. That program counter points to some location in memory, typically to the first instruction in the sequence. And those instructions, by the way, are very simple: they're things like, take the value out of two places in memory, and run them through the multiplier in here, a little piece of circuitry, and stick them back into someplace in memory. Or take this value out of memory, run it through some other simple operation, stick it back in memory. Having executed this instruction, that counter goes up by one and we move to the next one. We execute that instruction, we move to the next one. Oh yeah, it looks a whole lot like that. 
 
Some of those instructions will involve tests: they'll say, is something true? And if the test is true, it will change the value of this program counter to point to some other place in the memory, some other point in that sequence of instructions, and you'll keep processing. Eventually you'll hopefully stop, and a value gets spit out, and you're done. 
 
That's the heart of a computer. Now that's a slight misstatement. The process to control it is intriguing and interesting, but the heart of the computer is simply this notion that we build our descriptions, our recipes, on a sequence of primitive instructions. And then we have a flow of control. And that flow of control is what I just described. It's moving through a sequence of instructions, occasionally changing where we are as we move around. 
 
OK. The thing I want you to take away from this, then, is to think of this as, this is, if you like, a recipe. And that's really what a program is. It's a sequence of instructions. Now, one of things I left hanging is, I said, OK, you build it out of primitives. So one of the questions is, well, what are the right primitives to use? And one of the things that was useful here is, that we actually know that the set of primitives that you want to use is very straight-forward. 
 
OK, but before I do that, let me drive home this idea of why this is a recipe. Assuming I have a set of primitive instructions that I can describe everything on, I want to know what can I build. Well, I'm going to do the same analogy to a real recipe. So, real recipe. I don't know. Separate six eggs. Do something. Beat until the-- sorry, beat the whites until they're stiff. Do something until an end test is true. Take the yolks and mix them in with the sugar and water-- No. Sugar and flour I guess is probably what I want, sugar and water is not going to do anything interesting for me here-- mix them into something else. Do a sequence of things. 
 
A traditional recipe actually is based on a small set of primitives, and a good chef with, or good cook, I should say, with that set of primitives, can create an unbounded number of great dishes. Same thing holds true in programming. Right. Given a fixed set of primitives, all right, a good programmer can program anything. And by that, I mean anything that can be described in one of these process, you can capture in that set of primitives. 
 
All right, the question is, as I started to say, is, "What are the right primitives?" So there's a little bit of, a little piece of history here, if you like. In 1936, that same guy, Alan Turing, showed that with six simple primitives, anything that could be described in a mechanical process, it's actually algorithmically, could be programmed just using those six primitives. 
 
Think about that for a second. That's an incredible statement. It says, with six primitives, I can rule the world. With six primitives, I can program anything. A couple of really interesting consequences of that, by the way, one of them is, it says, anything you can do in one programming language, you can do in another programming language. And there is no programming language that is better-- well actually, that's not quite true, there are some better at doing certain kinds of things-- but there's nothing that you can do in C that you can't do in Fortran. It's called Turing compatibility. Anything you can do with one, you can do with another, it's based on that fundamental result. 
 
OK. Now, fortunately we're not going to start with Turing's six primitives, this would be really painful programming, because they're down at the level of, "take this value and write it onto this tape." First of all, we don't have tapes anymore in computers, and even if we did, you don't want to be programming at that level. What we're going to see with programming language is that we're going to use higher-level abstracts. A broader set of primitives, but nonetheless the same fundamental thing holds. With those six primitives, you can do it. 
 
OK. So where are we here? What we're saying is, in order to do computation, we want to describe recipes, we want to describe this sequence of steps built on some primitives, and we want to describe the flow of control that goes through those sequence of steps as we carry on. 
 
So the last thing we need before we can start talking about real programming is, we need to describe those recipes. All right, And to describe the recipes, we're going to want a language. We need to know not only what are the primitives, but how do we make things meaningful in that language. Language. There we go. All right. Now, it turns out there are-- I don't know, John, hundreds? Thousands? Of programming languages? At least hundreds-- of programming languages around. 
 
PROFESSOR JOHN GUTTAG: [UNINTELLIGIBLE] 
 
PROFESSOR ERIC GRIMSON: True. Thank you. You know, they all have, you know, their pluses and minuses. I have to admit, in my career here, I think I've taught in at least three languages, I suspect you've taught more, five or six, John? Both of us have probably programmed in more than those number of languages, at least programmed that many, since we taught in those languages. 
 
One of the things you want to realize is, there is no best language. At least I would argue that, I think John would agree. We might both agree we have our own nominees for worst language, there are some of those. There is no best language. All right? They all are describing different things. Having said that, some of them are better suited for some things than others. 
 
Anybody here heard of MATLAB Maybe programmed in MATLAB? It's great for doing things with vectors and matrices and things that are easily captured in that framework. But there's some things that are a real pain to do in MATLAB. So MATLAB's great for that kind of thing. 
 
C is a great language for programming things that control data networks, for example. 
 
I happen to be, and John teases me about this regularly, I'm an old-time Lisp programmer, and that's how I was trained. And I happen to like Lisp and Scheme, it's a great language when you're trying to deal with problems where you have arbitrarily structured data sets. It's particularly good at that. 
 
So the point I want to make here is that there's no particularly best language. What we're going to do is simply use a language that helps us understand. So in this course, the language we're going to use is Python. Which is a pretty new language, it's growing in popularity, it has a lot of the elements of some other languages because it's more recent, it inherits things from it's pregenitors, if you like. 
 
But one of the things I want to stress is, this course is not about Python. Strange statement. You do need to know how to use it, but it's not about the details of, where do the semi-colons go in Python. All right? It's about using it to think. 
 
And what you should take away from this course is having learned how to design recipes, how to structure recipes, how to do things in modes in Python. Those same tools easily transfer to any other language. You can pick up another language in a week, couple of weeks at most, once you know how to do Python. 
 
OK. In order to talk about Python and languages, I want to do one last thing to set the stage for what we're going to do here, and that's to talk about the different dimensions of a language. And there're three I want to deal with. 
 
The first one is, whether this is a high-level or low-level language. That basically says, how close are you the guts of the machine? A low-level language, we used to call this assembly programming, you're down at the level of, your primitives are literally moving pieces of data from one location of memory to another, through a very simple operation. A high-level language, the designer has created a much richer set of primitive things. In a high-level language, square root might simply be a primitive that you can use, rather than you having to go over and code it. And there're trade-offs between both. 
 
Second dimension is, whether this is a general versus a targeted language. And by that I mean, do the set of primitives support a broad range of applications, or is it really aimed at a very specific set of applications? I'd argue that MATLAB is basically a targeted language, it's targeted at matrices and vectors and things like that. 
 
And the third one I want to point out is, whether this is an interpreted versus a compiled language. What that basically says is the following: in an interpreted language, you take what's called the source code, the thing you write, it may go through a simple checker but it basically goes to the interpreter, that thing inside the machine that's going to control the flow of going through each one of the instructions, and give you an output. So the interpreter is simply operating directly on your code at run time. 
 
In a compiled language, you have an intermediate step, in which you take the source code, it runs through what's called a checker or a compiler or both, and it creates what's called object code. And that does two things: one, it helps catch bugs in your code, and secondly it often converts it into a more efficient sequence of instructions before you actually go off and run it. All right? 
 
And there's trade-offs between both. I mean, an interpreted language is often easier to debug, because you can still see your raw code there, but it's not always as fast. A compiled language is usually much faster in terms of its execution. And it's one of the things you may want to trade off. 
 
Right. In the case of Python, it's a high-level language. I would argue, I think John would agree with me, it's basically a general-purpose language. It happens to be better suited for manipulating strings than numbers, for example, but it's really a general-purpose language. And it's primarily-- I shouldn't say primarily, it is an interpreted language. OK? 
 
As a consequence, it's not as good as helping debug, but it does let you-- sorry, that's the wrong way of saying-- it's not as good at catching some things before you run them, it is easier at some times in debugging as you go along on the fly. 
 
OK. So what does Python look like? In order to talk about Python-- actually, I'm going to do it this way-- we need to talk about how to write things in Python. Again, you have to let me back up slightly and set the stage. 
 
Our goal is to build recipes. You're all going to be great chefs by the time you're done here. All right? Our goal is to take problems and break them down into these computational steps, these sequence of instructions that'll allow us to capture that process. 
 
To do that, we need to describe: not only, what are the primitives, but how do we capture things legally in that language, and interact with the computer? And so for that, we need a language. We're about to start talking about the elements of the language, but to do that, we also need to separate out one last piece of distinction. Just like with a natural language, we're going to separate out syntax versus semantics. 
 
So what's syntax? Syntax basically says, what are the legal expressions in this language? Boy, my handwriting is atrocious, isn't it? There's a English sequence of words. It's not since syntactically correct, right? It's not a sentence. There's no verb in there anywhere, it's just a sequence of nouns. Same thing in our languages. We have to describe how do you put together legally formed expressions. OK? And as we add constructs to the language, we're going to talk about. 
 
Second thing we want to talk about very briefly as we go along is the semantics of the language. And here we're going to break out two pieces; static semantics and full semantics. Static semantics basically says which programs are meaningful. Which expressions make sense. Here's an English sentence. It's syntactically correct. Right? Noun phrase, verb, noun phrase. I'm not certain it's meaningful, unless you are in the habit of giving your furniture personal names. 
 
What's the point? Again, you can have things that are syntactically legal but not semantically meaningful, and static semantics is going to be a way of helping us decide what expressions, what pieces of code, actually have real meaning to it. All right? 
 
The last piece of it is, in addition to having static semantics, we have sort of full semantics. Which is, what does the program mean? Or, said a different way, what's going to happen when I run it? That's the meaning of the expression. That's what you want. All right? You want to know, what's the meaning of this piece of code? When I run it, what's going to happen? That's what I want to build. 
 
The reason for pulling this out is, what you're going to see is, that in most languages, and certainly in Python-- we got lots of help here-- all right, Python comes built-in with something that will check your static, sorry, your syntax for you. And in fact, as a sidebar, if you turn in a problem set that is not syntactically correct, there's a simple button that you push that will check your syntax. If you've turned in a program that's not syntactically correct, the TAs give you a zero. Because it said you didn't even take the time to make sure the syntax is correct. The system will help you find it. In Python, it'll find it, I think one bug at a time, right John? It finds one syntax error at a time, so you have to be a little patient to do it, but you can check that the syntax is right. 
 
You're going to see that we get some help here on the static semantics, and I'm going to do an example in a second, meaning that the system, some languages are better than others on it, but it will try and help you catch some things that are not semantically correct statically. In the case of Python, it does that I think all at run time. I'm looking to you again, John, I think there's no pre-time checks. Its-- sorry? 
 
PROFESSOR JOHN GUTTAG: [UNINTELLIGIBLE] 
 
PROFESSOR ERIC GRIMSON: There is some. OK. Most of them, I think though, are primarily caught at run time, and that's a little bit of a pain because you don't see it until you go and run the code, and there are some, actually we're going to see an example I think in a second where you find it, but you do get some help there. 
 
The problem is, things that you catch here are actually the least worrisome bugs. They're easy to spot, you can't run the program with them there, so you're not going to get weird answers. Not everything is going to get caught in static semantics checking. Some things are going to slide through, and that's actually a bother. It's a problem. Because it says, your program will still give you a value, but it may not be what you intended, and you can't always tell, and that may propagate it's way down through a whole bunch of other computations before it causes some catastrophic failure. So actually, the problem with static semantics is you'd like it to catch everything, you don't always get it. Sadly we don't get much help here. Which is where we'd like it. But that's part of your job. 
 
OK. What happens if you actually have something that's both syntactically correct, and appears to have correct static semantics, and you run it? It could run and give you the right answer, it could crash, it could loop forever, it could run and apparently give you the right answer. And you're not always going to be able to tell. Well, you'll know when it crashes, that doesn't help you very much, but you can't always tell whether something's stuck in an infinite loop or whether it's simply taking a long time to compute. You'd love to have a system that spots that for you, but it's not possible. 
 
And so to deal with this last one, you need to develop style. All right? Meaning, we're going to try to help you with how to develop good programming style, but you need to write in a way in which it is going to be easy for you to spot the places that cause those semantic bugs to occur. 
 
All right. If that sounds like a really long preamble, it is. Let's start with Python. But again, my goal here is to let you see what computation's about, why we need to do it, I'm going to remind you one last time, our goal is to be able to have a set of primitives that we combine into complex expressions, which we can then abstract to treat as primitives, and we want to use that sequence of instructions in this flow of control computing, in order to deduce new information. That imperative knowledge that we talked about right there. So I'm going to start today, we have about five or ten minutes left, I think, in order-- sorry, five minutes left-- in order to do this with some beginnings of Python, and we're going to pick this up obviously, next time, so; simple parts of Python. 
 
In order to create any kinds of expressions, we're going to need values. Primitive data elements. And in Python, we have two to start with; we have numbers, and we have strings. Numbers is what you'd expect. There's a number. There's another number. All right? Strings are captured in Python with an open quote and some sequence of characters followed by a closed quote. 
 
Associated with every data type in Python is a type, which identifies the kind of thing it is. Some of these are obvious. Strings are just a type on their own. But for numbers, for example, we can have a variety of types. So this is something that we would call an integer, or an INT. And this is something we would call a floating point, or a float. Or if you want to think of it as a real number. And there's some others that we can see. 
 
We're going to build up this taxonomy if you like, but the reason it's relevant is, associated with each one of those types is a set of operators that expect certain types of input in order to do their job. And given those types of input, will get back output. 
 
All right. In order to deal with this, let me show you an example, and I hope that comes up, great. What I have here is a Python shell, and I'm going to just show you some simple examples of how we start building expressions. And this'll lead into what you're going to see next time as well as what you're going to do tomorrow. So. Starting with the shell, I can type in expressions. 
 
Actually, let me back up and do this in video. I can type in a number, I get back a number, I can type in a string, I get back the string. Strings, by the way, can have spaces in them, they can have other characters, it's simply a sequence of things, and notice, by the way, that the string five-- sorry, the string's digit five digit two is different than the number 52. The quotes are around them to make that distinction. We're going to see why in a second. 
 
What I'm doing, by the way, here is I'm simply typing in expressions to that interpreter. It's using its set of rules to deduce the value and print them back out. Things I might like to do in here is, I might like to do combinations of things with these. So we have associated with simple things, a set of operations. So for numbers, we have the things you'd expect, the arithmetics. And let me show you some examples of that. 
 
And actually, I'm going to do one other distinction here. What I typed in, things like-- well, let me start this way-- there's an expression. And in Python the expression is, operand, operator, operand, when we're doing simple expressions like this, and if I give it to the interpreter, it gives me back exactly what you'd expect, which is that value. OK? 
 
The distinction I'm going to make is, that's an expression. The interpreter is going to get a value for it. When we start building up code, we're going to use commands. Or statements. Which are actually things that take in a value and ask the computer to do something with it. So I can similarly do this, which is going to look strange because it's going to give me the same value back out, but it actually did a slightly different thing. 
 
And notice, by the way, when I typed it how print showed up in a different color? That's the Python saying, that is a command, that is a specific command to get the value of the expression and print it back out. When we start writing code, you're going to see that difference, but for now, don't worry about it, I just want to plant that idea. 
 
OK. Once we've got that, we can certainly, though, do things like this. Notice the quotes around it. And it treats it as a string, it's simply getting me back the value of that string, 52 times 7, rather than the value of it. Now, once we've got that, we can start doing things. And I'm going to use print here-- if I could type, in order to just to get into that, I can't type, here we go-- in order to get into the habit. I can print out a string. I can print out-- Ah!-- Here's a first example of something that caught one of my things. This is a static semantic error. 
 
So what went on here? I gave it an expression that had an operand in there. It expected arithmetic types. But I gave two strings. And so it's complaining at me, saying, you can't do this. I don't know how to take two strings and multiply them together. Unfortunately-- now John you may disagree with me on this one-- unfortunately in Python you can, however, do things like this. What do you figure that's going to do? Look legal? The string three times the number three? Well it happens to give me three threes in a row. 
 
I hate this. I'm sorry, John, I hate this. Because this is overloading that multiplication operator with two different tasks. It's saying, if you give me two numbers, I'll do the right thing. If you give me a number and a string, I'm going to concatenate them together, it's really different operations, but nonetheless, it's what it's going to do. 
 
STUDENT: [UNINTELLIGIBLE] 
 
PROFESSOR ERIC GRIMSON: There you go. You know, there will be a rebuttal phase a little later on, just like with the political debates, and he likes it as a feature, I don't like it, you can tell he's not a Lisp programmer and I am. 
 
All right. I want to do just a couple more quick examples. Here's another one. Ah-ha! Give you an example of a syntax error. Because 52A doesn't make sense. And you might say, wait a minute, isn't that a string, and the answer's no, I didn't say it's a string by putting quotes around it. And notice how the machine responds differently to it. In this case it says, this is a syntax error, and it's actually highlighting where it came from so I can go back and fix it. 
 
All right. Let's do a couple of other simple examples. All right? I can do multiplication. I've already seen that. I can do addition. Three plus five. I can take something to a power, double star, just take three to the fifth power. I can do division, right? Whoa. Right? Three divided by five is zero? Maybe in Bush econom-- no, I'm not going to do any political comments today, I will not say that, all right? 
 
What happened? Well, this is one of the places where you have to be careful. It's doing integer division. So, three divided by five is zero, with a remainder of three. So this is the correct answer. If I wanted to get full, real division, I should make one of them a float. And yes, you can look at that and say, well is that right? Well, up to some level of accuracy, yeah, that's .6 is what I'd like to get out. 
 
All right. I can do other things. In a particular, I have similar operations on strings. OK, I can certainly print out strings, but I can actually add strings together, and just as you saw, I can multiply strings, you can kind of guess what this is going to do. It is going to merge them together into one thing. I want-- I know I'm running you slightly over, I want to do one last example, it's, I also want to be able to do, have variables to store things. And to do that, in this it says, if I have a value, I want to keep it around, to do that, I can do things like this. 
 
What does that statement do? It says, create a name for a variable-- which I just did there, in fact, let me type it in-- mystring, with an equal sign, which is saying, assign or bind to that name the value of the following expression. As a consequence, I can now refer to that just by its name. If I get the value of mystring, there it is, or if I say, take mystring and add to it the string, mylastname, and print it back out. 
 
So this is the first start of this. What have we done? We've got values, numbers and strings. We have operations to associate with them. I just threw a couple up here. You're going to get a chance to explore them, and you'll see not only are there the standard numerics for strings, there are things like length or plus or other things you can do with them. And once I have values, I want to get a hold of them so I can give them names. And that's what I just did when I bound that. I said, use the name mystring to be bound to or have the value of Eric, so I can refer to it anywhere else that I want to use it. 
 
And I apologize for taking you over, we'll come back to this next time, please go to the website to sign up for recitation for tomorrow. 
펼쳐보기

작성참여하기  자막참여 히스토리 자막다운로드 

펼쳐보기
총 15강
  • 1강 : 컴퓨터과학과 프로그래밍 입문 (1): 강의 소개 및 목표

    1강 : 컴퓨터과학과 프로그래밍 입문 ..

    2강 : 컴퓨터과학과 프로그래밍 입문 (2): 연산자와 피연산자

    2강 : 컴퓨터과학과 프로그래밍 입문 ..

    3강 : 컴퓨터과학과 프로그래밍 입문 (3): 일반적인 코드 패턴

    3강 : 컴퓨터과학과 프로그래밍 입문 ..

    4강 : 컴퓨터과학과 프로그래밍 입문 (4): 분해와 추상 함수

    4강 : 컴퓨터과학과 프로그래밍 입문 ..

    5강 : 컴퓨터과학과 프로그래밍 입문 (5): 실수형

    5강 : 컴퓨터과학과 프로그래밍 입문 ..

    6강 : 컴퓨터과학과 프로그래밍 입문 (6): 이분법

    6강 : 컴퓨터과학과 프로그래밍 입문 ..

  • 7강 : 컴퓨터과학과 프로그래밍 입문 (7): 리스트와 변하기 쉬운 성질

    7강 : 컴퓨터과학과 프로그래밍 입문 ..

    8강 : 컴퓨터과학과 프로그래밍 입문 (8): 복잡도

    8강 : 컴퓨터과학과 프로그래밍 입문 ..

    9강 : 컴퓨터과학과 프로그래밍 입문 (9): 이진 검색

    9강 : 컴퓨터과학과 프로그래밍 입문 ..

    10강 : 컴퓨터과학과 프로그래밍 입문 (10): 함수 분할 정복

    10강 : 컴퓨터과학과 프로그래밍 입..

    11강 : 컴퓨터과학과 프로그래밍 입문 (11): 테스팅과 디버깅

    11강 : 컴퓨터과학과 프로그래밍 입..

    12강 : 컴퓨터과학과 프로그래밍 입문 (14): 객체 지향 프로그래밍 입문

    12강 : 컴퓨터과학과 프로그래밍 입..

  • 13강 : 컴퓨터과학과 프로그래밍 입문 (15): 추상 데이터 타입

    13강 : 컴퓨터과학과 프로그래밍 입..

    14강 : 컴퓨터과학과 프로그래밍 입문 (16): 캡슐화

    14강 : 컴퓨터과학과 프로그래밍 입..

    15강 : 컴퓨터과학과 프로그래밍 입문 (24): 강의 복습 - 컴퓨터 과학자들은 무엇을 하는가?

    15강 : 컴퓨터과학과 프로그래밍 입..

강의 댓글 [ 2 ]

댓글 폼
       
( 0 / 800byte )
강의 잘 보았습니다:) 비전공자가 프로그래밍에 대해 배우고자 할 때 큰 도움이 될 수 있는 강의가 될 것 같습니다!!
[2013/07/16 14:37.06]
[2011/02/16 23:08.14]
처음페이지이전페이지1다음페이지마지막페이지
관련 동영상 강의
컴퓨터 프로그램의 구조와 해석 (16)

컴퓨터 프로그램의 구조와 해석 (16)

응용과학 / 컴퓨터 과학
버클리대학

[컴퓨터 프로그램의 구조와 해석 : 16 강]

컴퓨터과학 II: 프로그래밍 추상화

컴퓨터과학 II: 프로그래밍 추상화

응용과학 / 컴퓨터 과학
스탠포드대학
컴퓨터 프로그램의 구조와 해석 (17)

컴퓨터 프로그램의 구조와 해석 (17)

응용과학 / 컴퓨터 과학
버클리대학

[컴퓨터 프로그램의 구조와 해석 : 17 강]

컴퓨터과학과 프로그래밍 입문

컴퓨터과학과 프로그래밍 입문

응용과학 / 컴퓨터 과학
MIT OCW
맥 OS X와 코코아 터치, Objective-C 와 Tools에 관한 소개

맥 OS X와 코코아 터치, Objective-C 와 Tools에 관한 소개

응용과학 / 컴퓨터 과학
스탠포드대학

[아이폰 어플리케이션 프로그래밍 : 1 강]

Sitemap