240826
별일 없이 지났다.
240827
1) 함수의 인과적 적층 구조는 스택에 비유될 수 있다는 글을 쓴 적이 있다. 실제로도 콜스택(call stack)이라는 이름으로 사용되며, 그러한 스택 하나하나는 스택 프레임(stack frame)이라는 내부 구조를 갖는다.
스택 프레임은 인자로 받은 매개변수, 호출 이후 절차가 종료된 다음 프로그램이 돌아가야 할 메모리 위치를 가리키는 반환 주소(return address), 지역 변수, 이전 스택 프레임의 시작 주소(=before extended base pointer)로 이루어져 있다.
그러니까, 함수를 호출하는 과정에서는 이러한 스택 프레임을 형성하고 매개변수나 반환 주소를 쑤셔넣는 작업이 암시적으로 진행되는 것이다. 함수는 호출 자체가 비용이다. 그럼에도 불구하고 함수화를 하는 게 나을 때가 있다. 시간복잡도와 공간복잡도의 trade-off 말고도, 컴퓨터 비용과 프로그래머의 비용 사이에도 trade-off가 존재하는 셈이다.
240828
1) 어셈블리어(assembly language)를 볼 일이 생겼다. 정말 더럽게 못 알아보겠더라. c언어를 x86-64 gcc 14.2 컴파일러로 컴파일한 결과를 읽은 건데, 이게 또 아키텍처별로, 운영체제별로, 컴파일러별로 다른 결과를 내뱉는다는 것에 현기증이 일었다. 그런데 꾸역꾸역 들여다보니까 하나는 알겠더라. 어셈블리어를 읽으려면 무조건적으로 CS 지식이 선행되어야 한다. 즉 어셈블리어는 CS 공부에 적합한 이정표일 수 있다는 점이다. 예를 들어 cpu에는 tsc(time stamp counter)라는 게 있고, 그걸 읽을 수 있는 rdtsc라는 어셈블리 명령어가 있다든가… 그 근처를 공부하면서 흥미로운 부분이많았다. 내가 만약 잘리지 않는다면 올해 말 즈음에는(ㅋㅋ) 어셈블리어를 공부하고 싶다.
240829
1) 좋은 코드의 조건은 유지보수성에 있다… 이렇게만 표현하면 의미가 없는 것 같다. 요약본을 외워서 인출한 것과 아는 사람이 요약을 해내는 것은 당장 그 순간에서는 비슷할 수 있어도 실제로는 동등하지 않다. 어떠한 대원칙은 가지고 있되 사례 수집과 예외 수집은 따로 해야 하는 것이다.
예를 들어 오늘 들은 이야기 중 하나를 요약하자면 "사람들은 코드의 함수를 볼 때 함수 인자의 자료형으로 동작을 추측한다"는 것이었다. 그럴싸했다. Python이나 JS에서는 자료형을 명시하지 않으므로 그럴 일이 없었고(ㅋㅋ) Java는 남의 코드를 볼 일이 없어서 전혀 생각도 못한 부분이었다.
동시에 함수가 해야 할 일, 책임에 대해서도 생각해봐야 한다. 책임을 어디까지 한정지을 것인지에 대해 생각하다 보면 코드가 분리되어야 하는 순간이 온다(적어도 내 경험에서 그 역은 일어난 적이 없다). 갈 길이 멀다.
240830
별일 없이 지났다.
240831
deliberate practice와 성실의 문제에 대해서는 포스팅을 쓴 적이 있다. 나는 여전히 성실이 거의 모든 것의 근본이라고 믿는다. 간신히 끝자락에 손이 닿은 듯했는데 지금 보면 그 약간의 성실마저도 빛이 바랜 것 같다. 건강을 되찾아야겠지.
240901
벌써 9월이라니 손발이 오들오들 떨리고 등골이 차갑고 집중이 안 되고…
요 몇 주를 돌아보면 피곤했던 것도 있지만 그와 별개로 추가적인 공부를 잘 안 했다. 알고리즘 문제도 스트릭 유지한다는 느낌으로 쉬운 문제만 풀고 있고. 사실 어려운 문제를 도전하긴 했는데 코드를 다 갈아엎어야 한다는 사실을 마주하고 나니 기운이 빠져서 미뤄두는 중이다. 역시 1일/1주 단위로 to-do를 작성하고 관리하는 게 맞지 싶은데… 포스트잇도 쓰다가 말았다. 이런 건 진짜 압력을 줘서 습관으로 정착할 때까지 지속해야 할 텐데 쉽지가 않네!
돌아보니 놀라운 사실들이 몇 개 없는데… 역시 사람이 자주 놀라기도 쉽지가 않다. 이번에는 자주 놀라는 한 주가 되었으면.