Let's not overthink sometimes Let's not overthink sometimes

보호되어 있는 글입니다.

영어로 생활하다보니 참 어려운 표현 중 하나가 unless인 것 같다. 물론 다들 알고 있는 얘기지만, 이는 if... not...으로 그리 어렵지 않게 보일 수 있다(심지어 Python은 if 조건문과 함께 unless 조건문도 있다). 어찌보면 별 것 아닌 것 같지만 실은 이메일이 아닌 일상 대화에서 이걸 얘기하기가 쉽지 않다. 일단, unless라고 말은 꺼내 놓고 그 다음에 음... 이젠 한번 부정을 했으니 더 이상 부정을 얘기할 필요는 없어...라고 생각하는 순간 말이 꼬이기 시작한다. 차라리 if...로 말을 꺼냈으면 그냥 더 나았을 것을... 지금까지 unless로 얘기해서 성공한 적이 없었다. T.T 한데, 깨달은 것이 있다, unless는 until과 비슷하다는 것을. 최근 들어서, un..

제대로 된(?) 섭우퍼를 들어본 적이 없어서인지 나는 섭우퍼를 탐탁치 않게 생각한다. 물론 이론적으로 따져 생각해보면 가장 이상적인 것은 맞다. 고음과 저음을 한 스피커를 통해 동시에 내게 되면 소리가 좀 뭉게지는 경향이 있다고 할까. 고음도 날카롭게 두드러지지 못할 뿐더러 저음도 쿵쿵 울림이 떨어질 것이다. 반면, 이를 분리해서 별도의 스피커를 통해서 내게 되면 아마도 가장 이상적이지 아닐까 한다. 일반 스테레오 스피커도 2-way, 3-way라고 하여 실은 이들을 따로 분리하는게 보통이다. 하지만 그럼에도 불구하고 난 서브우퍼에 대해선 편견을 가지고 있는데, 마치 contrived(?)되었다고 할까. 자연스럽지 못하고 좀 부담스러운 느낌이다. 이것 좀 들어봐 하면서 귀에다 억지로 밀어부치는 느낌이 든..

3rd party software를 최신 버전으로 업그레이드했다. 사실 이런 작업이 개발자로선 가장 고달프다. 대부분의 개발자는 자기가 친숙한 소스 파일만을 건드리길 원하지, 그리고 수정한 소스가 클릭 한 번에 빌드가 되는 것을 원하지, 빌드 환경을 고쳐가며 "왕창(?)" 수정하기를 원하지 않는다. 게다가, 해 내더라도 별로 인정을 받지 못한다고 생각한다, "그거 그냥 갖다 붙이면 되는 거잖아."하는 소리가 두렵다. T.T Cmake 문서를 보아가며 숨가쁘게 고쳐나가다가 나중에 제대로 동작하지 않는 것을 발견했다. Temporary로 생성되어야 하는 파일을 찾지 못하겠다는 한 줄 에러만 뿌릴 뿐, 왜 생성하지 못했는지에 대해서 아무런 단서가 없다. 그 파일이 뭐하는 놈인지, 어떻게 생성되는 건지, pyt..

이제 고등학교를 다니기 시작한 아들이 물리에 관심이 많은데, 물리를 하려면 수학을 잘 해야 한다는 아들의 얘기에... 난 그건 옛날 수학 얘기고 요즘 수학은 그렇지 않다고 얘기를 시작했었다. 물리는 고작 수학의 일부분만, vector calculus를 가져다 쓸 뿐이라고 얘기했다. 헐... T.T 영화 "박사가 사랑한 수식"에 보면 수학자가 생각하는 가장 "아름다운(?)" 공식이라면서 오일러 항등식이 나온다. 물론, 이는 대학교 응용수학(공업수학?)의 복소수 부분에서 증명하고 있는 다음의 오일러 공식을 통해 바로 유도될 수 있다. 오일러 시대만 하더라도 만들어 낼 수학 공식이 남아 있었고, 인도의 라마누잔은 무한대(∞)를 다루는 수학 공식을 만들었지만... 나의 비천한 생각으로 이젠 더 이상 수학 공식을..

가끔은 Tree 자료 구조가 필요할 때가 있다. 예를 들어, 파일 시스템의 디렉토리 구조를 이름만 가지고 추적하고자 할 때가 그런데, 각 노드(즉, directory)는 list인데, leaf (즉, 파일) 혹은 자식 노드를 (즉, subdirectory) 원소로 가지는 list로 나타낼 수가 있다. 물론, 실제 linux 파일 시스템도 크게 다르진 않아서, 파일/디렉토리를 나타낼 때 이름 대신, 그 inode를 (디스크 상의 주소?) 사용한다는 것이 다르다고 할까. .Net에선 어떤지 모르겠지만, C++ STL에선 linked list, set, queue, dictionary, heap 같은 자료 구조들은 다 지원하면서 유일하게도 tree는 없다. 적어도 red-black tree 같은 전형적인 bi..

"There is only one way to do it"은 당시 Perl을 경쟁 상대로 생각했기 때문이었을 것이다. Perl을 좋아하는 나로서도 사실 Perl의 syntax가 제멋대로인 것은 좀 보기 좋지 않다. 100이면 100, 각기 다른 스타일로 Perl 코딩을 하기 때문에 다른 사람 코드를 하나 보려면 처음 펼쳐보는 순간 눈 앞이 좀 막막하다, 이건 마치 다른 programming language로 적혀진 것 같다. 그 사람 코드에 익숙해지기 위해 일단 시간이 필요하다. Object-Oriented Programming (OOP) 외에 Python이 그 절대적인 중요성을 깨우쳐 준 것이 하나 있다면, readability일 것이다. 어찌보면, 컴퓨터공학 관련된 사람이 아닌 이상 C 같이, "{"..

지난 시절 Object-Oriented Programming (OOP)가 유행이었지만 그리 대단한(?) 것은 아니라고 생각하는데, 사실 Haskell은 OOP를 전혀(?) 지원하지 않지만 OOP를 감히 딱 한줄로 요약하는 것 같다, "OOP는 function call을 infix operator 형태로도 쓸 수 있다는 것에 불과하다". 즉, f(a, b) 대신 a.f(b)로 쓸 수 있다는 것인데, Haskell에선 이미 infix function call을 지원해서 이를 a `f` b로, infix 형태로 쓸 수 있다. 즉, OOP는 syntactic rule에 불과하다는 관점. 그러면, data hiding이나 inheritance (그리고 그에 따른 polymorphism)은 어떡하냐고 할텐데... ..