Materialistic

Rust를 처음 시작하는 입장에서 당황스러울 만한 점 중 하나로 세미콜론의 사용을 들 수 있다. 비슷한 시기에 등장한 Swift나 Go 같은 언어에서는 문장 끝에 세미콜론을 쓰지 않는 것과 다르게, Rust는 C나 Java처럼 세미콜론(;)이 필수인 언어에 속한다. Python이나 Ruby 이후에 등장한 언어들이 대체로 세미콜론을 빼는 쪽으로 문법을 정하는 경향이 있었던 걸 생각해보면 조금 특이한 점으로 볼 수 있겠다.

앞서 말한 대로 문장 끝에 세미콜론을 생략할 수 없기 때문에, 다음과 같은 코드는 당연히 컴파일 에러가 난다. (Rust Playpen)

fn main() { let a = 1 let b = 2 println!("{} + {} = {}", a, b, a + b) }

anon:3:5: 3:8 error: expected one of `.`, `;`, or an operator, found `let` anon:3 let b = 2 ^~~

하지만 여기서부터부터가 당황스러운 지점인데, 아래 코드는 문제 없이 컴파일을 통과한다.

fn main() { let a = 1; let b = 2; println!("{} + {} = {}", a, b, a + b) }

마지막 문장에 한해서 세미콜론을 생략할 수 있는 걸까? 코드를 다음처럼 바꿔 보면 더더욱 혼란스러운 결과를 볼 수 있다. (Rust Playpen)

fn main() { let a = 1; let b = 2; println!("{} + {} = {}", a, b, a + b); a + b }

anon:5:5: 5:10 error: mismatched types: expected `()`, found `_` (expected (), found integral variable) [E0308] anon:5 a + b ^~~~~ anon:5:5: 5:10 help: see the detailed explanation for E0308 error: aborting due to previous error

에러 메시지를 잘 보면 이게 세미콜론이 빠졌다는 얘기하곤 조금 다른 것 같다. 타입이 안 맞는다고? ()는 또 뭐지? 결론부터 얘기하면 다음과 같은 규칙들 때문이다.

Rust에서 거의 대부분의 문장은 수식으로 취급된다.

흔히 3항 연산자라고 불리는 a ? b : c 꼴의 조건 문법이 Rust에는 없는데, if나 match와 같은 문장이 그대로 수식으로 간주되기 때문이다. 다시 말해 아래와 같은 코드를 짤 수 있다.

println!("{}", if a % 2 == 0 { "even" } else { "odd" });

세미콜론은 여러 문장을 연결한다.

다른 언어에서는 세미콜론이 단순히 문장을 끝낸다는 의미만을 가지는 반면, Rust에서는 여기에 덧붙여, 세미콜론으로 연결된 문장들의 가장 마지막 문장을 전체 문장의 '결과 값'으로 하는 기능이 있다.1 짧게 예를 들면, a; b는 먼저 a를 실행한 뒤 그 결과를 버리고, b를 실행한 결과와 같은 값이 된다. 그래서 여러 문장을 { ... } 블록으로 묶으면, 이 블록의 마지막 문장의 값이 블록 밖으로 '리턴'되는 효과가 난다.

이걸 응용하면 아래와 같은 코드를 쓰는 것도 가능하다.

let numbers = { let mut vec = vec![]; for i in (0..5) { vec.push(i); } vec };

a;은 a; ()과 같다.

여기서 ()은 일명 unit 타입이라 불리는 것으로, C나 Java의 void 타입과 비슷한 역할을 맡는다.2 또한, 위 예제에서의 main() 함수처럼 리턴 값이 없는 함수는 ()을 리턴하는 것으로 취급된다.

함수의 가장 마지막 문장이 세미콜론으로 끝나지 않는다면, 그 문장은 암묵적으로 함수의 리턴 값이 된다.

따라서 아래와 같은 함수를

fn add(a: i32, b: i32) -> i32 { return a + b; }

이렇게 줄여 쓸 수 있게 된다.

fn add(a: i32, b: i32) -> i32 { a + b }

이제 위의 예제를 다시 되짚어보자. 두 번째 코드에서 println!("{} + {} = {}", a, b, a + b)이 문제 없이 통과됐던 것은 println!(..)의 결과 값이 ()이고, 이것이 main() 함수의 리턴 타입인 ()와 같았기 때문이다. 세 번째 코드가 실패했던 것 또한 가장 마지막 문장인 a + b의 타입이 ()가 아닌 무언가이고3, 이것이 main()의 리턴 타입과 맞지 않아서였다.

얼핏 실수로 삽질하기 딱 좋은 문법이라는 생각이 들지만, 실수를 해도 Rust가 강타입 언어이기 때문에 타입 시스템에 의해 컴파일러가 잡아 줄 거라고 다들 생각하는 것 같다. 대다수의 관용적인 Rust 코드가 이 특성들을 적극적으로 사용하니 Rust를 배우고자 하는 사람이라면 이런 코드들에 익숙해지는 것이 좋겠다.

만약 C에 익숙하다면 C의 콤마 연산자(,)가 이것과 비슷하다는 걸 눈치챘을 것이다. ↩︎

하지만 void 타입과 다른 점이 하나 있는데, C나 Java에서 void 타입의 값은 존재하지 않지만, Rust의 () 타입은 ()이라는 값을 딱 하나 갖는다. 굉장히 쓸모 없어 보이지만 의외로 Option<T>나 Result<T, E> 타입 같은 걸 쓸 때 유용하게 써 먹을 수 있다. 자세한 얘기는 이 포스팅의 주제를 벗어나니 다음 기회에 다루도록 하겠다. ↩︎

The HTTP must not be used for internal messaging as it’s easy, but not simple, quite the contrary it’s complicated protocol with 5 RFCs describing only basics. And misunderstanding smallest part of spec may lead to a security vulnerability

어쨌거나 웹 브라우저나 로드 밸런서 등 널리 사용되는 HTTP 기반 도구들의 도움을 받을 수 있다는 점에서, HTTP를 저런 용도로 쓰지 말아야 한다는 주장에는 그렇게까지 강하게 동감하진 않는다. 하지만 HTTP가 간단한 프로토콜이 아니라는 데에는 동의하는데, 안 그럴 것 같지만 스펙을 하나하나 훑어 보면 생각 외로 개지랄같이 복잡한 프로토콜이기 때문이다. 상태 없는 메시지 단위 프로토콜이라는 범주 안에서 상상해 볼 만한 온갖 스펙들이 HTTP에 들어 있다. 내용 협상(content negotiation), 인증, 캐시 메커니즘 아래에서 무엇이 언제까지 캐시할 수 있는지 명시할 수 있는 갖은 방법들, 별별 상황에 대해 정의되어 있는 상태 코드들과 메서드마다 규정된 동작 방식들은 애교에 가깝고, 연결 비용을 줄이기 위한 Keep-Alive, 웹소켓이나 HTTP/2 등의 다른 프로토콜로 옮겨가기 위한 Switching Protocol 메커니즘, 그리고 그거 아는가? User-Agent 헤더의 내용을 브라우저마다 제멋대로 쓰고 있는 것 같지만 사실 거기에도 정해진 형식이 있다.

HTTP를 가지고 내부 서비스나 외부에 제공할 API 같은 걸 만들기 시작하면 흔히 둘 중 하나의 결과로 수렴하게 된다. 모든 요청을 POST로 때우고 모든 응답을 깡그리 200 OK로 때우는 바람에 HTTP 본문 위쪽으로는 1바이트도 읽을 필요가 없을 정도인 API를 만들거나, 반대로 HTTP 스펙을 가능한한 준수하고자 하는 욕망에 사로잡혀서 RFC를 법전처럼 읽어내리는 시간을 보내다가 주화입마에 빠지거나.

php의 이상함을 느낄 만한 사람들은 진작에 php를 버리거나 어떻게든 php에서 벗어나려 하고1, php를 쓰면서 뭐가 이상한지 모르는 사람들은 여전히 php에 눌러앉은 채로 지낸다.2

성평등에 관심이 있던 사람이 오히려 여성 혐오 이슈에도 먼저 관심을 가지고, 그런 데에 관심이 없는 사람에게는 누군가가 직접 혐오 발언을 지적해도 없는 문제 취급한다.

무언가가 필요한 사람에게 정작 그 무언가를 전달하기가 가장 어렵다는 것은 인간 사회에 보편적으로 존재하는 문제인 것 같다.

http://hacklang.org/ 이렇게. php를 옹호하는 흔한 레퍼토리에서 등장하는 바로 그 Facebook의 작품이다. ↩︎

애자일 이야기 – 음의 생산성

주의: 이 내용은 Swift와 Xcode beta 발표 초기의 변화 내용을 담고 있습니다. 이 글이 쓰여진 이후로도 Swift에는 많은 변화가 있었고, 2014년 9월 현재 Xcode 6 정식 버전이 출시된 상태이므로, 정확한 정보를 얻기 위해서는 Apple에서 제공하는 Swift 최신 문서를 참조해주시길 바랍니다.

※ 자세한 변경점은 릴리즈 노트를 참고 (Mac Dev Center에 로그인 필요)

Array<T>를 선언하는 또 다른 방법인 T[]가 이제 [T]로 변경됨. 또한, 이제 Dictionary<K, V>를 [K:V]로 선언할 수 있다.

혼란스러웠던 Array<T>의 변경 가능성(mutability)과 복사 관련 동작이 Dictionary와 String, struct와 같이 값으로서의 의미론(value semantic)을 따르도록 고쳐짐.

이전에는 배열을 let으로 선언해도 배열의 길이를 바꾸는 연산1만 금지될 뿐, 배열 원소를 수정하는 건 가능했으며, var로 선언했을 때도 배열 원소를 수정하는 연산으론 배열이 복제되지 않았었다.

이제는 배열을 let으로 선언하면 완전한 읽기 전용이 되어 길이 변경은 물론 원소 수정도 불가능한 상태가 되고, var로 선언하고 배열 원소를 수정하는 것도 변경으로 간주되어, 길이를 바꿀 때와 마찬가지로 별개의 배열로 복사되게 됨.

1부터 10 이전(즉 1부터 9)까지를 의미하는 1..10과 1부터 10까지를 의미하는1...10이 서로 혼동되는 문제를 피하기 위해, .. 연산자가 ..<으로 변경됨.

외부에서 불러온 C 함수가 CInt, CFloat 등의 타입 대신 Int32, Float 등을 쓰도록 바뀜

외부에서 불러온 C 함수가 사용할 포인터 값에 관한 API가 좀 더 간단하게 바뀜

nil이 단순한 상수 이름에서 언어 리터럴로 편입. NilLiteralConvertible 프로토콜을 구현하면 nil을 받을 수 있는 타입을 만들 수 있음.

이외에 Swift 언어 자체의 변경점은 아니지만, Swift 소스 코드 안에 ASCII가 아닌 문자가 들어 있으면 자동 완성이 안 되던 Xcode 버그가 이번 베타에서 고쳐졌다고 한다.

그렇다면 현 세대의 정적 타입 언어들은 이 부분에서 동적 타입 언어에 대한 경쟁력을 갖고 있을까? Go의 interface나 Rust 및 Swift의 확장 가능한 타입, C# 등이 가진 향상된 제네릭 타입 등은 이 문제를 해결하는가? Haskell의 type class는 어떤가? 최근까지 학술계의 전유물에 가까웠던 dependent type이 도입된다면 타입 시스템의 이상을 깨지 않고 동적 타입에 비할 만한 유연성을 얻을 수 있을까? 오히려 반대의 일이 일어나진 않을까?

Apple이 얼마 전에 발표한 새로운 프로그래밍 언어인 Swift의 내부 구조, 그 중에서도 객체 모델에 집중해서 해설한 글.

요약하면, Swift 객체 모델은 메시지가 빠진 Objective-C 모델과 유사하다. 바이너리에 들어가는 클래스 정보는 Objective-C의 그것과 거의 같은 구조이지만, Swift 클래스임을 나타내는 특별한 비트가 있고, Objective-C 메서드는 하나도 포함하지 않는다. 이는 Objective-C가 메서드 호출을 objc_msgSend()라는 내부 함수를 통한 메시지 패싱으로 처리하는 반면에, Swift에서는 C++의 것과 유사하게 정적 디스패치 혹은 vtable을 활용한 동적 디스패치를 하기 때문이다.1

Objective-C의 객체 모델이 정적 타입 언어보다는 오히려 Smalltalk, Python, Ruby 등의 동적 타입 언어에 가까운 것처럼, objc_msgSend() 또한 메서드 이름2을 가지고 런타임 중에 상속 트리를 따라 올라가면서 맞는 메서드가 있는지 일일이 탐색하는 방식을 사용하고 있다. 이에 반해 Swift는 일반적인 C 함수 호출과 거의 비슷한 비용으로 메서드 호출을 처리할 수 있으며, 최적화를 좀 더 과격하게 하면 충분히 인라이닝까지 노려볼 수 있다. 메서드 호출이 애플리케이션 실행 중에 엄청나게 많이 일어나는 작업이란 것을 감안하면 Swift가 Objective-C 대비 수십 배도 빨라질 수 있다고 광고하는 것도 무리가 아닌 셈이다. 현실은 그놈의 integer overflow check 때문에 벤치마킹에서 신나게 털리고 있지만3

여담으로, 위에서 보았듯이 Swift의 메서드 디스패치 방식이 Objective-C와 호환되지 않기 때문에, NSObject 계통의 클래스를 상속받지 않은 Swift 객체는 Objective-C 코드에선 직접 부를 수가 없다. 두 언어의 메서드 명명 방식이 조금씩 다른 문제도 있고 해서, Swift에서는 아예 Objective-C 쪽에서 부를 수 있는 이름을 따로 명시할 수 있는 @objc attribute를 제공하고 있다.

Objective-C의 경우 반대로 vtable 영역이 비어 있다고 한다. (http://blog.zynamics.com/2010/07/02/objective-c-reversing-ii/) ↩︎

그래도 메서드 이름을 문자열로 탐색하는 건 아니고, 컴파일할 때 셀렉터라는 값으로 바꿔서 사용한다. ↩︎

1929년에 있었던 미합중국 대 슈치빔메르 소송에서 재판관 올리버 웬델 홈즈 2세가 제기한 반대 의견 중에서 인용.

평화주의자였던 로시커 슈치빔메르는 미국에 귀화하기를 원했지만, 인터뷰 도중 "나라를 지키기 위해 개인적으로 무기를 집어들 것"을 자신의 신념에 의해 거부했고, 그 결과 위 소송이 제기되게 되었다. 올리버 홈즈의 의견에도 불구하고 최종 판결은 슈치빔메르에게 미국 시민권을 부여하는 것을 거부하기로 결정되었지만, 이 판결은 훗날 1946년 기로워드 대 미합중국 소송에서 다시 뒤집어지게 된다.

참조: 파리13구님의 이글루 — 사상의 자유란?

/r/programming 서브레딧에 올라온, Xwt라는 라이브러리를 소개하는 글에 달린 댓글, "나는 모든 플랫폼에 딱 어울리는 크로스 플랫폼 GUI 라이브러리를 본 적이 없다"고 쓴 댓글에 덧붙여서.

크로스플랫폼 GUI 툴킷에 대한 내 생각과 아주 가까운 의견http://t.co/gNsNbOhHRX크로스플랫폼 GUI 툴킷이 모두 엉망인 이유는 재밌게도 모두들 시각적으로 보이는 것들을 추상화했기 때문이다. 너무 저수준의 추상화라 의도가 휘발된다.

— Hong Minhee (@hongminhee) 2013년 7월월 30일

월드 와이드 웹의 시대가 오고, 리눅스 얹은 OS와 유닉스 얹은 OS가 나란히 세상을 지배하는 기묘한 시대가 왔지만, 나에겐 오히려 MS의 압제 밑에 있던 시절보다도 내 장비에 대한 통제권이 없다. 모처럼 받은 게임이 버벅대는가? 아마 핸드폰을 통째로 갈아치워야 할 것이다. 맘에 안 드는 번들 앱 몇 개 없애는 데에 핸드폰이 벽돌이 되거나 A/S 권리가 날아갈 각오를 해야 하는 데다, 심지어 그냥 같은 OS를 최신으로 업그레이드하는 것조차 제조사가 넘겨주지 않는 이상 똑같은 각오를 해야 한다. 어디서나 웹 브라우저를 통해 내 데이터에 접근할 수 있다는 건 분명 편리한 일이지만, 정작 그 데이터들은 내 손아귀를 벗어나 저 바다 건너일지 어디일지 모를 곳에서 누군지도 모르는 이가 지켜보는 곳에 널브러져 있을 것이다. 네이티브 앱이라고 해도 상황이 별로 달라지지는 않는다. 클라우드 속 어딘가에 구름처럼 흩뿌려져 있거나, 운이 없으면 나조차도 접근할 수 없는 플래시 메모리 어딘가에 처박혀 있거나. 표준화되고 공개된 웹과 잘 정리된 서비스 API 덕분에, 이전에는 생각조차 못 했던 방법으로 데이터를 다뤄서 멋진 웹 서비스를, 심지어 혼자서라도 그런 것을 만들어낼 수 있게 되었지만, 그런 걸 할 수 없는 사람들에게는 결국 자유란 없는 것이다.

First of all you must realize that programming is a continuous learning process, it does not matter how much you know, there is always much more to learn. The next thing to realize is that professional programming is first of all a team activity, you must work and develop together with your colleagues.Think about programming as a team sport, where nobody can win a whole match alone.