[고찰] 언어 철학 학습

 

필자는 다른 프로그래밍 언어를 공부하는것을 좋아한다. 흔히들 언어는 도구에 불과하다고 말하고, 필자 본인조차도 기초지식 글에서 쓸데없이 언어를 확장하지 말라고 하기도 했다.

 그러나 그럼에도 불구하고 본인은 프로젝트에서 쓰지않는, 타 언어를 공부하는것을 좋아한다. 그리고, 내가 주로 사용하는 언어와 다르면 다를수록 좋다.

이 글에서는, 내가 기술스택을 공부하는거보다 언어 공부를 선택하는 이유를 포스팅 하고자 한다.

 

필자는 왜 프로그래밍 언어를 학습하는것을 좋아할까?

프로그래밍 언어는 그자체로써 수준높은 프로그램이다.

 흔히 프로그래밍 실력을 늘리기 위해서는 좋은 코드를 많이 보라고 말한다. 좋은 코드를 많이 보다보면 자연스럽게 그런식으로 프로그래밍하도록 노력하게 되기때문이다.

 좋은 코드는 좋은 프로그램을 만든다. 좋은 프로그램이란 추상화가 잘되있는 코드이다. 코드 자체를 보는것 뿐만 아니라 좋은 프로그램을 사용하고, 해당 프로그램이 어떻게 구현했을까, 왜 이렇게 했을까? 이런 UX 를 가진 이유가 뭘까? 이런것을 고찰하는것 자체로도 충분히 가치 있는 일이라고 생각한다. 로우 레벨한 동작원리나 코드 한줄한줄을 파보지 않더라도, 추상화된 개념 자체에대한 고찰과 프로그램의 해결방법등을 공부할수있다.

 프로그래밍 언어는 개발자가 가장 많이 사용하는 프로그램 그 자체다. 그리고 가장 만나기 쉽고, 학습하기 쉽다.

프로그래밍 언어에는 창시자의 고찰과 고뇌, 그리고 철학이 그대로 들어가있다.

 사실 이 이야기를 하려고 포스팅하였다.

 난 자바를 좋아하지는 않지만, 존경하는 언어이다. OOP 의 대표 주자로써, 객체지향적인 사고를 위하려 노력한 모습이 보인다. 개인적으로 "상속" 이라는 단어 자체를 좋아하지 않는데 "확장된다"는 의미가 잘 느껴지지 않기 때문이다. 여기서 자바는 인터페이스, 클래스를 상속받을때 implements 와 extends 를 사용한다. 인터페이스는 해당 함수가 존재한다는 약속이기 때문에 implements를 쓰고,  클래스 상속은 부모 클래스가 확장된다는 의미로써의 extends 를 쓴거 같은데, 아주 탁월한 언어 선택이라고 본다.

 자바8에 추가된 스트림은, 타 언어와 달리 map/reduce/filter를 쓰려면 귀찮게 stream으로 변환해야한다.  인터페이스에 새로운 메서드를 추가해도 이전 버전의 구현체가 규약을 어기지 않게 지원하기 위함이라고 한다. 새로운 표현식을 사용하지 않고 인터페이스를 사용하여 람다 표현식을 사용한다. 기존 컬렉션 프레임워크의 체계를 뒤흔들기보다는 람다와 어울려 쓰기에 좋은 인터페이스로 Stream을 새롭게 도입하고 기존 인터페이스에도 기본 메서드로 람다를 지원하는 메서드를 추가해 안정적인 개선을 추구했다. 거기에 내부 구현도 쉽고, 성능도 높혔다. [관련링크]

 왜 C++는 this를 사용하는가? 글에서 왜 C++ 는 self 를 사용하지 않고 this를 썻는가에 대한 이유가 나온다. 단순히 this 라는것이 뚝딱 생겨서, this 가 아니라 이런것 하나에도 언어 개발자의 고찰이 들어간다는 의미이다.

 이처럼 프로그래밍 언어는 자연어와 다르게 언어 개발자의 설계로 부터 탄생했다. 언어 개발자의 철학이 고스란히 담겨있고, 원인과 결과가 있다. 이렇게 창시자의 고뇌와 해결 및 표현 방법을 얻는다는것은 마치 내가 제임스 고슬링과 스트로스트룹씨에게 철학을 배우는 느낌을 준다.

상속을 그냥 : 으로 표현하는것이 수준이 더 낮다는 의미가 아니다. this 가 self보다 철학적이다는 소리가 아니다. 개인적으로는 : 으로 상속을 표현하는것을 더 선호한다. 위의 예시처럼, 원인과 결과에 대한 고찰이 느낄수 있다는것이 좋다는 소리다.

위와 같은 이유들로 나는 프로그래밍 언어를 학습하는것을 좋아한다. 그러나 단순히 언어의 문법을 공부하고, Keyword 를 학습하며, 언어만의 기술을 공부하는것을 선호하는것이 아니다.

프로그래밍은 시를 쓰는것에 가깝다.

 한글을 공부한다고, 한글로 된 시를 쓸수있는것이 아니다. 한국어와 일본어가 문법이 비슷하지만, 일본어 단어만 공부한다고 일본어로 뚝딱 시를 쓸수도 없는 노릇이다. 한국어로 된 시를 일본어로 번역하는거는 가능하지만, 이는 번역이지 시를 쓴것이 아니다. 해당 국가에 맞는 시를 잘쓰기 위해서는 해당 국가의 문화와 환경을 알아야한다.

 프로그래밍도 똑같다고 본다. C# 이 Java 를 배껴 만들었다고 Java 개발자가 Java for 대신 C# for 를 쓴다고 C# 개발자가 되는것이 아니다. 이건 포팅이지 프로그래밍이 아니다. Kotlin 이 더 나은 자바를 지향한다고 switch 문대신에 when을 쓴다고 kotlin을 배운것이 아니다.

 필자는 언어를 배운다는건 그 언어의 환경과 철학을 공부한는것이라고 생각한다. OOP FP 와 같은 패러다임은 일종의 문화권이고, C# Java 와 같은 언어는 하나의 국가와 비슷하다고 생각한다. 이러한 부분은 걸출한 서적을 정독하지 않는이상, 단순히 언어 문법을 찾아보고 공부한다고 알수있는것이 아니며, 스스로 공부하면서 지속적으로 "왜?" 라는 의문을 던지며 스스로 찾아봐야한다.

 예를 들어 "Clojure 는 Lisp 계열이기 때문에 매크로가 존재한다. 단 다른 Lisp 에 존재하는 리더 메크로는 없다." 라는것을 봤을때. 아 clojure는 메크로존재, 리더매크로 X 가 아니라 왜 리더메크로는 없는지, Lisp 계열이라 메크로가 왜 존재하는지 궁금해하며 배우는것이 좋다고 본다.

 

마지막으로...

 프로그래밍 언어는 도구라고 한다. 뭐.. 틀린말은 아니라고 본다. 닭을 잡는 데 어찌 소 잡는 칼을 쓸까. 하지만 칼과 톱은 원리도 다르고 사용법도 다르다. 칼로 무엇인가를 자를때, 톱으로 썰듯자르지 않는거처럼, 프로그래밍 언어는 도구지만 도구끼리의 철학은 다른다.

 기술 스택보다 프로그래밍 언어를 선호하는 이유라고 글을썻지만, 사실 기술 스택도 다르지 않다고 본다. 기술스택도 도구에 가깝고, "암기" 하는 부분이지만 분명히 나온 원인이 있고, 설계 철학이 있다. 다만 프로그래밍 언어를 공부하는것에 비하여 "암기" 의 양이 보다 많다고 개인적으로 생각할 뿐이다. 간단히 말하자면 언어를 공부할때는 수학을 공부하는 느낌이고, 기술 스택을 공부할때는 한국사를 공부하는 느낌이다.

 필자는 이렇게 실컷 말했지만, 호기심이 많아서 이거 저거 찔러보는것을 좋아하고, 사실 수박 겉핥기 식으로 공부하는게 많다. 그러나 보다 근본적인 원인과 결과, 그리고 개발자의 고찰을 깊게 이해하고자 노력은 하고있다.

글을 잘 못쓰기 때문에... 전달되지 않은 부분이나, 왜곡된 부분이 분명 존재할것이므로 너그럽게 이해 부탁드립니다.