deer-develop / study

2 stars 0 forks source link

와 큰일나따... #2

Open deerhamyungjin opened 5 months ago

deerhamyungjin commented 5 months ago

처음에 의기차게 읽기 시작했다. 하지만 12p 불 대수부터

누구나 그럴싸한 계획은 있다. 쳐 맞기 전까지는

의 감각이 온몸을 감싸기 시작했고, 24p의 명세에 이르러서는 눈으로 글자를 읽지만 뇌에서 글자를 받아들이지 않는 상태가 됐다. 급기야 32p의 하드웨어 구현에서

Not Nand 게이트 하나로 구현할 수 있다.

를 읽는데 육성으로 '그렇겠지... 이 스터디에서 나빼고 다른 사람들은...'이라고 육성으로 말이 튀어 나왔다. 하지만 결국 1장에서 얘기하고 싶은 것은

우리 Nand로 진짜 개 쩌는 거 할거야. 그니까 Nand 를 기반으로 이러 저러한 걸 만들수 있는데(게이트) 그거 2,3장에 써야 하거든? 그니까 너가 한번 만들어바 ㅎㅎ 아, 우리가 만들기 좋게 다 판도 깔아놔써(HDL) 그니까 어 너도 할 수 있으니까 함 해봐 ㅎㅎ

인 것 같다.

뭔가 이제까지 내가 경험하던 세계란 전혀 다른 묘사방식(언어라고 쓰려다 어울리지 않는 표현이라고 생각이 들었음)으로 신세계에 발을 들이는 기분이다. 보통 나같은 쫄보는 이럴 때(신세계에 발을 딪을 때)걍 믿을만한 사람(여러분)부여 잡고 일단 따라가는 법이다. 대충 섬에 내릴 때 조로 팔에 엉겨 붙어있는 우솝을 생각하면 딱 맞을 거 같다.

복잡한 시스템을 다루기 좋은 모듈로 분할정복하는 인지 능력은, 각 모듈의 추상화abstacton구현 mplementaton을 식별하는 사고방식에 의해 강화된 다. 컴퓨터 과학에서 이 용어는 구체적인 의미로 쓰인다. 즉, 추상화는 모듈 이 무엇을 하는지를, 구현은 어떻게 하는지를 가리킨다.

라는 문장이 좋았다. 분할->추상->무엇을하는지 와 정복->구현->어떻게 하는지 가 마치 제품을 개발할 때 태도나 의식과 비견해도 될 법한 표현이라고 생각됐다. 그 다음에 바로

어떤 모듈이든 구성 블록으로 사용할 때는 모듈의 추상화에만 집중하고, 상세 구현은 완 전히 무시해야 한다는 점이다

라는 문장이 튀어나와서 항상 기획에 문제를 정의할 때 하는 실수를 여기서도 지적받으며 뼈맞는 기분도 함께 들었다.

부록이 더 중요한 것 같다. 지금(1/18) 읽기 시작했다. 망했다 ㅜ

Deocksoo commented 5 months ago

적을 것이 없네요

Deocksoo commented 5 months ago

명재: 과제를 할 수 있을것같나요? 명진 : 답을 못찾을것 같으면 참고서 답안지 보고 답 찾는게 더 효율적이다. 이 방식을 쓰면 시간을 좀 많이 쓰면서라도 과제 할 수 있을것같다!

명재: 이거 절대 이해 안된다, 하는 부분은 없었는지?? 명진: 명사 부분에서 왜 그렇게 되는건지 잘 이해가 안됐다. 스펙 적어둔 부분들, 이름들이 이해가 잘 안됐음.

Deocksoo commented 5 months ago

혜원: 좋네요

Deocksoo commented 5 months ago

혜원 : 이해 안 됐던 것의 예시가 있을까? 명진: 기능 명세만 봐서는 뭐 하는 것인지 이해가 안 된다.

deerhamyungjin commented 5 months ago

리턴 = 아웃

Deocksoo commented 5 months ago

명진: 예를 들면 Mux의 기능 명세같은 경우, 이게 대체 뭘 하는지 이해가 안 된다. 덕수: 이게 구현 대상 과제라서 지금은 이해가 안 될수밖에 없을거다. 그냥 일종의 브랙박스라고 보면 된다. 명재: 프로그래밍 언어에서 보면 input으로 parameter가 들어가고, return 대신 out이라고 보면 된다.