정적타입vs동적타입?? 단순한 언어가 최고!!

요즘 재미있게 시청하였던 "알아두면 쓸데 없는 신비한 잡학사전: 알쓸신잡" 이라는 나PD가 만들고 유시민작가등이 출연하는 프로그램에서 따와서 "알아두면 쓸데 없는 재밌는 소프트웨어 지식:  알쓸재소" 이야기 하나 합니다. 그냥 가볍게 읽으세요~이런거 논쟁 할 시간에 실질적으로 사람들에게 필요한 서비스를 만드는데 집중 하는게 응용개발자들의 덕목이라고 생각하니까요 ~:-) 

https://dev.to/danlebrero/the-broken-promise-of-static-typing

위의 블로그 글을 간략하게 번역/정리/추가 해본것입니다.
 

---

 

엉클 밥 마틴(클린코드의 저자) 은 자신의 블로그에 이런 글을 올려 놓았는데요. "타입전쟁" 

로버트 마틴, Robert Martin (Uncle Bob) (@unclebobmartin),은 1970년부터 프로그래머로 일했다. 그는 현재 8th Light inc 라는 회사에서 Master Craftsman 이라는 직함으로 일하고 있으며, 전세계에서 열리는 수많은 컨퍼런스에서 인기를 누리는 발표자이며, 다음과 같은 수많은 책들을 쓰기도 했다: The Clean Coder, Clean Code, Agile Software Development: Principles, Patterns, and Practices, UML for Java Programmers. 그는 수많은 기사들을 쓰고, 논문들을 발표하면서도, 블로그 활동도 활발하게 하고 있다. 그는 C++ Report의 편집장(Editor-in-chief)으로 활동했고, Agile Alliance의 초대 의장으로도 활동했다.

그는 여기서 "테스트 주도 개발이 주요하게 될 것이며, 동적언어가 잘 나갈 것이다. 결국 더 적고 간단하게 말하는 놈이 이긴다."  라고 동적언어에 대한 긍정적인 얘기했었습니다.(역주: 동적타입의 문제는 테스트를 통해서 해소되며 , 이렇게 잘 해소할 수 있는데 굳이 타입이라는 굴레에 얽매일 필요가 없다고 말합니다.. 즉 타입문제를 실수와 연관해서 말하고 있습니다. 강타입,상속등을 통한 설계에 대한 이야기는 아님) 

뭐 이런 주장에 대해서 별로 납득하지 않는 정적타입언어 추종자들도 많을 것이다. 타입이 있기 때문에 불필요한 유닛테스트 비용이 없어지고, 좀 더 안정적이 될 수 있다고 주장하며 , 정적 타입 언어인 헤스켈은 이렇게 말하기도 함 " 일단 당신의 코드가 컴파일되면 바로 사용 될 수 있을 것이다!" 즉 정적타입 언어를 통해서 명확한 코드리딩, 더 안전한 리팩토링, 더 나은 문서화, 더 정확하고 많은 것을 도와줄 수 있는 IDE 제작, 이런 모든것들을 약속하죠. 한마디로 " 버그를 더 적게 만든다" 라고 주장합니다.

네 전 버그를 매우 싫어합니다. 이것들은 나의 소중한 시간들을 갉아먹고 있으며, 프로젝트의 원할한 진행을 위한 에너지를 소모시키죠. 따라서 언어별로 버그가 어떻게 발생되고 있는지 조사하였습니다.

언어별 버그 조사

그래서 각 언어들이 발생시키는 버그를 Github 를 통해 살펴 봤습니다.

녹색은 발전된 정적타입언어들 : 하스켈,스칼라,F#
오렌지는 오래되고 지루한 정적타입언어들: Java, C++, Go
빨강은 동적타입언어들: Javascript, Ruby, Python, Clojure, Erlang 

Round 1.  버그 밀집도 :  모든 저장소

Round 2. 버그 밀집도 :  10 stars 이상의 저장소

Round 3. 버그 밀집도 :  100 stars 이상의 저장소

좀 빈약한 증거라는 것은 부정 할수 없지만,  (역주: 해당 언어로 만드는 프로젝트가 보통 어떤 복잡도를 가지냐에 따라서도 달라질테니..) 어쨋든 동적타입군이 버그정도가 약합니다.

정적vs동적은 큰 이슈가 아니다.

정말 중요한것은 얼마나 단순한가에 따르는거 같습니다. Go 창시자인 롭파이크나 클로저의 창시자 리치하키는 그들의 언어의 코어와 단순화에 대해서 좋은 이야기를 해 주었었는데요. 

단순화는 어플리케이션을 좀 더 이해하기 쉽고, 변경하기 쉽고, 유지하기 쉽게 만들어 주며 그 결과 버그의 숫자에도 영향을 미칠 것 입니다. 그럼 단순화된 언어는 무엇일까요? 여기 리스팅 해보겠습니다.

Go, Erlang and Clojure 의 공통사항이기도 하죠.:

• No 수동메모리관리
• No 뮤텍스기반의 동시성 구현
• No 클래스
• No 상속
• No 복잡한 타입 시스템
• No 멀티파라다임
• Not 많은 구문들 
• Not 학구적 

(역주: 개인적으로는 No 클래스 제외하고는 동의 합니다. 우연적 복잡성은 저기에서 기인한다고 생각) 

Tony Hoare 의 말로 글을 끝내죠.

두가지 방식의 소프트웨어 디자인 방식이 있습니다. 한가지는 단순화해서 명백히 결함이 없게 만드는 것이고, 다른 방식은 복잡하게 만들어서 명백한 결함이 없도록 만드는것입니다.

(There are two ways of constructing a software design: 
one way is to make it so simple that there are obviously no deficiencies; 
the other is to make it so complicated that there are no obvious deficiencies.) 

역주:
Tony Hoare (토니호어) : 호어이론, 퀵정렬로 유명합니다. 널포인터를 만든 사람으로도 알려져 있으며 후에 "널포인터는 10억달라짜리 실수" 라고 말하기도 하였습니다. 스위프트, 러스트, 하스켈, 스칼라, 코틀린 등은 널포인터 실수를 방지 할 수 있는  optional type을 가지고 있는 대표적인 언어들입니다. 이러한 언어에서는 널 포인터를 사전에 컴파일러가 차단하므로 널 포인터 오류가 나지 않습니다. 사용자가 의도치 않게 널 포인터를 양산하는것을 강제적으로(?) 막죠. 

P.S 

전 만들려고 하는게 간단하던, 복잡하던 죽어도 클래스는 못버려~~타입인지라 (정적,동적은 상관없음) 
Go,Clojure 를 할 생각이 없지만, 언젠가 한번 버려서 제작은 해봐야지~라는 열린 생각은 가지고 있습니다.  

참고로 : http://philoskim.github.io/doc/why-clojure.html 

여기 링크에는 파이썬와 비교해서 클로저의 장점을 말하고 있는데, 이 글을 동의해서 시도해 봐야지 라고 생각 보다는, 그냥 언젠가 시도는 해 볼 생각은 하고 있습니다. 항상 내가 익숙한것 끌리는 것만 하고 사는것은 재미없는 인생이니까 말이죠. 남들이 재밌다는 영화/만화책은 한번 읽어봐주는 아량(?) 처럼 ㅎㅎ