수학의 짜여진 공리체계 내에서 생각하는게 익숙할 테니 프로그래밍 언어론을 공부하면 되겠군요.


근데 기본적으로 말해 둘 것은,

프로그래밍도 결국은 정해진 인풋을 어떻게 아웃풋으로 만드냐는 측면에서는 대수의 한 집합 위의 사상(mapping)하고 비슷합니다.
컴퓨터는 기본적으로 계산기고, 이 계산기에 어떤 데이터를 집어넣고 어떤 연산을 순차적으로 시행하여 원하는 값을 얻는 게 프로그래밍의 목표죠.
하지만 계산기이니만큼 기본적으로 원하는 시간 내에 수학의 계산에 정확하게 답을 내주기엔 한계가 있고,
따라서 공학적으로 이런 한계를 줄이거나 적어도 비슷한 값을 내주는 것이 프로그래밍이기도 합니다.
따라서 코드는 수학적으로 올바르지 않을 수도 있습니다. 원하는 시간 내에 답을 내기 위해 수학적으로 틀린 알고리즘을 사용하기도 합니다.
그래서 컴퓨터 공학이 \'공학\'인 겁니다.-.-;

근데 간단한 시퀀스 컨트롤 구문인 while문을 몰랐다는 걸 보면 이 문제가 아니라 기본적으로 프로그래밍을 구성하는 것들을 모른다는 말과 다름없으니,
프로그래밍이 어떤 요소들을 갖고 이 요소들을 어떻게 사용하여 주어진 문제를 해결하는지 이해할 필요가 있어 보입니다.

http://imtl.skku.ac.kr/imtl/index.php?page=course&submenu=programing2010

일단 제가 학부수업을 듣는 교수님의 강의 페이지를 링크해 드립니다. 강의 책도 나와 있고, 수학자이시니 영어 읽는건 이미 일상화되셨다고 믿습니다.


진짜 말하고 싶은 건 이제부터입니다.

시간이 돈보다 더 중요한 나이시라지만 새로운 지식은 돈을 줘도 얻어지지 않습니다. 
남에게 이해시켜 달라는 태도는 지식인으로서의 태도로 보기엔 별로 좋지 않습니다.

시간 쓰시기 싫으시다면 의뢰자로서의 적절한 태도를 가지시는게 좋습니다.
개발자의 코드를 한라인씩 이해하고 틀린 점을 찾으려 하기보다 정해진 시간 내에 아웃풋을 내지 못하는 개발자는 그냥 자르는게 훨씬 적절한 갑의 태도입니다.-_-
사실 개발자의 코드를 보고 뭔가를 이해하려는 갑의 태도는 을인 개발자에게 심대한 스트레스를 안겨주게 됩니다. 
기본적으로 개발자에게도 어느 정도의 남을 이해시키기 위한 문서화 능력은 요구되긴 하지만, 그건 후임 개발자를 위해 어느 정도 해당 분야에 지식이 있는 공학자가 이해할 수준의 문서를 만드는 것이고, 비공학자를 이해시킬 용도라면 아주 추상적인 내용들만 하거든요. 왜냐고요? 효율 문제죠..-.-