타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).

난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.

누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 엘리트주의를 끌어들이기 쉽다: 「어떤 시스템이 오작동하는 것은 아키텍처가 나쁘기 때문이다. 아키텍처가 나쁜 이유는 그걸 설계한 프로그래머가 수준 미달이기 때문이다」와 같이.

반면 타입 시스템은 일단 도입만 하면 누구나 그 덕을 볼 수 있다. 팀 내의 프로그래머들의 역량이 뛰어나든 뛰어나지 않든. 훨씬 평범한 보통 사람에게 유리하다. 타입 시스템이 미봉책일 수는 있지만, 그 미봉책이 더 많은 사람들을 프로젝트에 참여할 수 있게 해준다고 생각한다.

5

❤️

5 people reacted.

Uncertified Quasi-pseudo dev

지금까지 다루어 봤던 언어는 아래와 같습니다. MSX Basic Z80 Assembly Pascal GW-Basic C Macromedia Director Visual Basic PHP Flash Actionscript C++ Javascript

그리고 지금은, 하스켈을 비즈니스에 쓰려고 몇 년간 노력하고 있습니다. 지금 상태는, 하스켈 자체를 연구하는 게 아니라, 하스켈 (혹은 함수형 언어) 이해가 어려운 이유를 연구하는 아마추어 연구가쯤 되어버렸습니다. 하스켈 주제로 블로그를 운영 중이지만, 아직은 하스켈 프로그래머라고 자신 있게 말하진 못하고 있습니다. 가끔 이해에 도움이 될만한 측면이 보이면, 가볍게 아이디어를 여러 SNS에 올려보곤 하는데, 그다지 프로그래머에게 쓸모 있는 내용이 포함되진 않는 것 같습니다.

A hobbyist photographer, football fan and ex software engineer.

This account is for my personal records. I mostly post in Korean, but I can communicate in English and Japanese.

I use tags for my photo posts.