4 min to read
Go 언어를 쓰기전에(마무리편)
이전 포스트입니다.
2017년 4월 2일에 작성된 문서를 재 가공한 포스트입니다. 해당 포스트를 작성했었을 때에는 자위용에 불과해서 자위용포스트는 전부 지워버렸습니다.
세상을 재미있게 만들기 위하여!!
주의
이 블로그의 내용은 대단히 주관적인 내용이 가득합니다.
그리고 양질의 글을 읽었지만 똥글이 나오는건 제 미숙함 때문입니다.
그럼에도 불구하고 피드백 많이 주신다면 자세히 조사하여 반영하도록 하겠습니다.
또한.. 가능한 링크로 올려놓은 자료들은 반드시 열어보시기 바랍니다. 분명 도움이 될 것입니다.
(- -)(_ _)
사람들(Gopher)에게 물어보았다. 고의 철학과 정의 및 페러다임.
Go 언어를 공부한지 6일 째
고 언어의 철학과 개발자들의 인식 그리고 이 언어에 대한 소감을 알고싶어졌다.
Go 의 강조되는 특징
- 고 언어의 동시성 패턴 ( 고 루틴과 채널 영상 그리고 영상게시글에 있는 ppt 자료)
고 언어의 페러다임
없지도 않고 있지도 않다. 이 언어가 무슨 페러다임이다! 라고 명확히 정의 내릴 수 없는 그런 언어. 위키에서는 Paradigm compiled, concurrent = 동시성 프로그래밍, imperative, structured 언어로 구분하지만, Closure는 되지만 함수형 헬퍼가 공식제공되는 언어도 아니다. 그렇기 때문에 무척 애매할 수 밖에없다.
다양한 사람들의 의견
-
makes it easy to build simple, reliable, and efficient software. 간단하고 안정적이며 효율적인 소프트웨어를 쉽게 만들 수 있습니다. https://golang.org 의 공식 소개 말
- (책을 추천해주기도 했다.)(도서)하룻밤에 읽는 Go 언어 이야기
- 개발자의 실력수준을 적게 타서 다양한 수준의 개발자 팀 구성시 유리한 실용적 언어이면서 시대적으로 뒤떨어지지 않는 언어라 생각합니다.
레전설의 답변
- Jhonghee Park(Go lang Korea 운영진) 님이 생각하는 Go의 정의 및 철학을 일단 맛본다면 조금은 감이 잡히지 않을까 한다.
” 제가 아는 Go는 그닥지 철학적이지도 학자연 하지도 않은 언어네요. 타입 시스템에 관심이 많고 언어이론에 통달하신 분들 한테는 재미 하나도 없는 언어이고 객체지향이던 함수형이던 어떤 특정한 프로그래밍 패러다임의 렌즈로 들여다 보기 시작하면 모든 분야에 2% 모자라는 언어입니다.”
” 프로그래밍 언어 개발을 전문적을 하는 분들이 모여 만든 언어도 아니고 단지 언어를 개발할 능력이 있는 고수들이 자기들의 필요를 충족시키기 위해 시작한 언어인지라 지극히 실용성에 촛점을 맞춘 언어라고 볼 수 있지요. Brad Fitzpatrick가 말한대로 “Get shit done language”라고 보입니다. 단순함과 간결함을 장점으로 유지하기 위해 애쓰기 때문에 다른 언어들에 비해 개발시 Cognitive overload 현상이 덜합니다.”
Object Composition, Composition Over inheritance, Higher-Order function, purity of function and immutability of function that feature of functional programming,
” 멀티 패러다임 언어이지만 각 패러다임의 모든 것을 구현하지는 않습니다. 객체지향이지만 전통적인 의미의 상속대신 composition을 강조하는 언어이고 higer-order function, closure등을 이용해 함수형 언어처럼 쓸 수는 있지만 함수의 purity나 공유데이터의 immutability를 보장하지도 않습니다. Go언어 자체에 많은 걸 기대하시면 실망만 남습니다 “
그리고 이런 답변이 달렸다.
제가 Go 언어에 대해 생각하는것과 비슷해서 여쭙습니다. 한가지 궁금했던 점은 말씀하신 것 처럼 Go의 inheritance 대신 composition 을 강조하는 언어 설계 특성인데 왜 이런 결론에 도달했을까요. Ingeritance vs Composition : KLDP , Inheritance < composition
그리고 Jhonghee Park 님이 다시 답변을 달았다.
우선 대형 소스코드 베이스에서 일해 보신 분들이라면 동의하실 것 같은데 지난 20년간의 객체지향성의 독주속에서 inheritance의 이론적 명료함이 실제로 현실에서는 남용, 오용되어 오히려 코드의 가독성을 떨어뜨리고 복잡성을 높이는 결과를 초래하는 경우가 적지 않았다고 봅니다.
Go의 디자이너들은 객체지향성에 대해 그런 접근법보다는 오히려 인터페이스의 장점을 최대로 살릴 수 있는 쪽으로 디자인 했다고 보여지네요. 그래서 인터페이스 자체도 명시적이지 않고 duck typing과 유사한 형태로 가지고 간 것이고요. inheritance를 바탕으로 하는 코딩은 배경에 이미 개발자가 타입의 hierarchy(계층적 구조)를 어느정도 숙지한 상태를 가정하는 경우가 상당하다고 보여집니다.
하지만 실제 코딩에서 greenfield(Greenfield dev. vs Brwonfield dev.) 프로젝트만을 할 수 없고 대부분 남이 만들어 놓은 코드를 확장하던지 조합해야 하는데 inheritance를 주무기로 했을때 이미 또 다른 abstraction의 층을 구성하게 되는 결과를 만듭니다. 복잡성이 수직적으로 자라는 약순환이 시작되는 것이지요. Go언어의 디자이너들을 이런 점을 피하고자 했던게 아닐까요.
다시 응답이 달렸다.
일리있는 말씀 감사합니다. 애초에 다루는 문제가 자연스러운 계층 구조를 가지고 있을 때, 여전히 inheritance design pattern 을 쓰는게 맞다는 생각은 지울 수 없네요. 디자인 단계에서 오남용 될 때의 단점이 장점을 상쇄한다고 생각했나보네요. 감사합니다
그리고 Jhonghee Park 님이 다시 답변을 달았다.
찾아보니 Golang팀의 공식 입장도 있네요. go official page#ingeritance
느낀점 및 결론 그리고 정리
난 솔직히 이 둘이 무슨말을 하는지 모르겠다. 그래서 본문의 단어들이나 키워들을 알 수 있도록 링크를 달아보았다. 100 퍼센트중에서 20퍼센트밖에 이해못했다. 역시 난 아직 미숙아인가 보다. 그럼에도 불구하고 갓갓한 분들의 의견을 정리해보면
- 시스템 언어에 대해 통달한 사람이라면 재미 없는언어. (C 로 짜면 되거든!)
- 즉, 시스템 언어에 통달하지 못한사람과 협업하기 위해서는 C보다는 Go를 선택하라.
- Go는 어떠한 페러다임의 성질을 가지고 있지만 특정 페러다임이다! 라고 정의내릴 수 없다.
- 고차함수와 클로저 비슷한 기능을 지원하여 함수형이라 하자니 함수형 언어의 성질을 보장하지 않음. (함수의 순수성(Purity)이라던지 불변성(Immutability)이라던지..)
- 즉.. 단순하게 그냥 멀티페러다임 언어라 부르면 된다.
- 상속성(Inheritance)과 구성성(Composition) 을 강조하는 언어.
- interface 의 존재로 상속성을 만들수 있지만 애초에 구성성(Composition)이 실제 코드상에서 강조되는 페턴을 짜기 힘들다. 이유는 아무래도 실력인대 괴수가 어렵다하면 나한태도 무척 어려울지도…
- 이 어렵다고 하는것은 Ingeritance design pattern 의 오용 및 남용으로 인해 그렇게 느끼는것이라 볼 수 있다.
- 병렬처리 및 동시성이 강조되는 언어
- Goroutines 과 Channel의 조합이 그러한 특징들을 만들어준다.
Comments