[기사] C++ 창시자 비야네 스트롭스트룹Bjarne stroustrup 인터뷰 번역

https://yozm.wishket.com/magazine/detail/2093/

“개발자가 수학에 투자하는 시간은 절대 낭비가 아닙니다” C++ 창시자 인터뷰 | 요즘IT

요즘IT에서 위 번역글을 재밌게 읽었다.

그래서 원문을 찾았는데, 꼼꼼하게 읽어보고 싶어서 인상깊은 구절을 직접 번역해봤다.

 

https://evrone.com/blog/bjarne-stroustrup-interview

C++ Creator Bjarne Stroustrup Interview by Evrone

Evrone: There is a widespread opinion nowadays that using modern frameworks is more important than applying math knowledge. Could you give any advice to young programmers regarding this?
인터뷰어: 최근에는 모던 프레임워크를 사용하는 것이 수학적 지식을 적용하는 것보다 중요하다는 인식이 널리 퍼져있습니다. 이에 관해 젊은 프로그래머들에게 조언을 해줄 수 있나요?

Bjarne: Time spent on math is never, well, rarely, wasted. Math is one of the best ways to train our brains, especially when combined with computing so that our mistakes become obvious pretty soon. Math teaches us to be accurate and not to believe in oversimplified or simply false ideas.
비야네: 수학에 들인 시간은 절대로, 뭐 웬만해선, 낭비가 아닙니다. 수학은 우리의 뇌를 훈련시키는 가장 좋은 방법 중에 하나로, 특히 컴퓨팅과 결합했을 때는 실수를 더 빨리 발견하게 해줍니다. 수학은 정확성을 길러주고, 지나치게 단순화되거나 잘못된 지식을 믿지 않도록 해줍니다.

1. There are areas where math is essential, such as scientific computing, some forms of graphics, and much of the financial software, but for most people the key areas of math is probability and statistics. Is your code fast enough? Will it scale? What are the likely events, and their implications?
계산 과학, 일부 그래픽 분야 그리고 많은 금융 소프트웨어들처럼 수학이 필수인 분야도 있습니다. 하지만 대부분의 사람들에게 핵심적인 수학 지식은 확률과 통계입니다. 코드가 충분히 빠른지? 확장성이 있는지? 발생할 수 있는 이벤트들과 그것의 영향은?

2. Of course, many applications don’t require math. However, if you build infrastructure or if you deploy an application at scale, capacity and energy costs enter the picture and mathematical naivety can cause harm.
많은 어플리케이션들이 수학 지식을 요구하지 않습니다. 하지만 당신이 인프라를 구축하거나 대규모 어플리케이션을 배포한다면 용량과 비용이 중요해지고 이 때 수학에 무지해서는 피해를 일으킬 수 있습니다.

* at scale : 대규모의

* enter the picture : 중요해지다

 

Evrone: Sometimes we, as developers, can't find a proper solution for a programming task at hand. Have you experienced such situations, and could you share any recommendations on how to deal with them?
인터뷰어: 개발자로서 눈 앞에 닥친 문제의 해결법을 찾지 못할 때가 있습니다. 그런 상황을 겪어보셨는지, 그리고 그런 상황에서 어떻게 해야하는지 추천해주실 수 있나요?

Bjarne: Of course! Nobody trying to do something novel or significant hasn’t spent hours, days, or longer being stuck and feeling awful and frustrated.
물론 겪어봤죠! 참신한 일을 시도하는 사람 중에 몇 시간, 며칠, 혹은 그보다 긴 시간동안 막혀서 좌절해보지 않은 사람은 한 명도 없을 겁니다.

1. You always try to look logically at the problem to understand it. Measure, if there is anything that you can measure to get feedback. Think hard about what you are trying to do: maybe you are not doing it or maybe the requirements you have come up with are not reasonable. Occasionally, take a break and think of something else. If I can, I go for a run. Then, often, some useful ideas pop into my head as I’m relaxing.
문제를 이해하기 위해서 항상 논리적인 태도로 접근해야합니다.  피드백을 얻기 위해서 정량화할 수 있는 게 있다면 정량화하세요. 무엇을 하려는지 곰곰히 생각하세요. 어쩌면 그렇게 하고 있지 않거나 떠올린 요구사항이 맞지 않을 수도 있습니다. 가끔 휴식을 취하거나 다른 것을 떠올리세요. 저 같은 경우에는 달리기를 하러 갑니다. 그러면 긴장이 풀리면서 쓸 만한 아이디어가 머리에 떠오릅니다.

 

Evrone: There is an (in)famous joke that any architecture problem can be solved by introducing a new layer of abstraction. Except for the problem of too many abstraction layers. A lot of C++ code we saw had an exceeding number of abstractions. Any advice from the language author on how to keep abstractions count at bay?
인터뷰어: 아키텍처 문제는 추상화 레이어를 추가함으로써 해결될 수 있다는 유명한 (악명높은) 농담이 있습니다. 추상화 레이어가 너무 많아진다는 문제만 빼면요. 그동안 봤던 많은 C++ 코드는 매우 많은 추상화를 가지고 있었습니다. 언어의 창시자로서 추상화가 많아지는 것을 방지하는 조언이 있을까요?

Bjarne: That’s David Wheeler’s “First law of computing”. I appreciate that you remember the second half – many people forget that, yet it is essential. (...) That “joke” reflects reality, probably more today than when David made it. People keep hiding the real work behind multiple levels of interfaces involving indirections. That can cost a magnitude or two in size and/or run-time. Much of modern C++ exists to allow people to have decent interfaces that a compiler can collapse into simple machine code without redundant indirections.
비야네: 데이비드 휠러의 "컴퓨팅 제1법칙" 이군요. 많은 사람들이 인용하면서 후반부를 빠뜨리는데, 중요한 부분을 잊지 않아주셨네요. 그 "농담"은 데이비드가 그 말을 만들었을 때보다 요즘의 현실을 더 반영합니다. 사람들은 간접지정을 포함한 여러 층의 인터페이스 뒤에 진짜 작업을 숨깁니다. 이것 때문에 크기나 런타임이 몇 배나 늘 수 있습니다. 최신 C++의 상당부분은 불필요한 간접지정 없이도 컴파일러가 심플한 기계어 코드로 바꿀 수 있도록 하는 인터페이스를 제공합니다.

* keep something at bay: (문제의) 발생을 막다

* 간접지정, 참조 indirection : 연산 대상으로 취급해야 할 데이터 항목의 기억 장소를 직접 지정하는 것이 아니라, 그 데이터 항목의 기억 장소를 기억하고 있는 주소를 지정한다.

 

Evrone: Many people think of you as their mentor. Could you share your vision — what qualities should a good mentor have, for example, inside of the company/team?
인터뷰어: 많은 사람들이 당신을 멘토로 생각합니다. 회사나 팀에서 좋은 멘토가 되기 위해 어떤 자질을 가춰야 하는지, 비전을 공유해주실 수 있나요?

Bjarne: A willingness to listen and to be serious about understanding the problem. Then, a degree of humility when it comes to giving advice – often, our understanding is incomplete. That said, a good Mentor must give concrete advice, not just general vague twaddle. If someone honors you with a serious question, it deserves a serious answer that helps the questioner to move forward. Giving advice is hard.
비야네: 경청하려는 의지, 그리고 진지하게 문제를 이해하려는 태도입니다. 그리고 조언할 때의 겸손함도 필요합니다. 때때로 우리의 이해는 불완전하니까요. 그렇기 때문에 좋은 멘토는 일반적이고 모호한 말이 아닌 구체적인 조언을 줄 수 있어야 합니다. 만약 어떤 사람이 진지한 질문을 함으로써 경의를 표한다면, 질문자를 앞으로 나아가게 할 수 있도록 진지한 대답을 해줘야 합니다. 조언을 주는 것은 어려운 일입니다.

 

 

이 글을 적으면서 데이비드 휠러의 인용구를 찾다가 아래와 같은 사이트를 찾았다.

https://johngrib.github.io/wiki/jargon/another-level-of-indirection/

또 다른 수준의 간접층

윗 글에 이런 말이 나온다.

패러다임 불일치
때때로 내부적인 구현에 대한 패러다임과 여러분이 만든 인터페이스의 패러다임이 일치하지 않을 수 있다. 보통 이러한 차이점을 감추기 위해서 어댑터를 만든다.

<Prefactoring> 11장 106쪽

이렇게 보니 좀 더 이해가 되는 것 같다.

 

프레임워크처럼 만들어져있는 추상화 계층들 (인터페이스)를 그대로 받아들이지 말고

기계어에 대한 이해를 바탕으로 스스로 추상화된 구조를 설계할 수 있는 능력이 필요한 것 같다.