가끔 하스켈, 함수형 글이 나오면 호기심을 가지고 눌러보는 게 내 눈팅 속성임. 그러면서 겉핥기한 지식으로 공상에 빠지곤 함.


하스켈 가독성이 안 좋은 이유를 누가 올렸는데 어느 정도 맞아 보이지만 난 그게 전부라는 생각이 안 들었음. 그걸 아는 사람들이 왜 하스켈 코딩만 하면 그 지경이 되는가를 설명하지 않았기 때문임.


OOP 프로그래밍의 핵심은 this라고 생각함. 이 암시 문맥 덕분에 코드 작성 단축과 자동완성의 편의를 누릴 수 있음. 재사용 단위가 객체 단위로 커지는 트레이드가 있지만 트레이드로 보지도 않을 만큼 널리 받아들인 방식이지.


이게 하스켈로 넘어오면, 암시 문맥을 온전히 표현하는 문제라고 하면 모나드를 반환하는 함수를 짜야함. 실제로 모나드 하나만 사용하는 하스켈 코드는 꽤 깔끔해 보이기도 함.


pUri :: Parser Uri pUri = do uriScheme <- pScheme void (char ':') uriAuthority <- optional . try $ do -- (1) void (string "//") authUser <- optional . try $ do -- (2) user <- T.pack <$> some alphaNumChar -- (3) void (char ':') password <- T.pack <$> some alphaNumChar void (char '@') return (user, password) authHost <- T.pack <$> some (alphaNumChar <|> char '.') authPort <- optional (char ':' *> L.decimal) -- (4) return Authority {..} -- (5) return Uri {..} -- (6)


하지만 현실에서 암시적 문맥은 중첩되기 마련이고 여기서 하스켈 이펙트 시스템은 GG를 침. 위의 파싱코드에서 로깅을 넣고 싶다? 난이도가 갑자기 산으로 감.


그리고 현실은 모나드조차 잘 쓰지 않음. 모나드 자체도 상당히 복잡한 기능이라 재사용성을 낮춘다는 생각임. 이 결과로 나온 코드가 총체적 난국인 거임. 인자는 전부 써줘야하고 필요한 데이터 있으면 최상위부터 접근해서 빼와야 하고…




내가 예전에 썼던 글을 재탕하는 느낌도 들지만 결국 하스켈은 도전적인 언어고 일부 고인물들이 이펙트 시스템 쪽을 계속 연구하고 있다고 보면 됨. 리액트 훅도 algebraic effect의 아이디어를 빼와서 사용했지만 이것저것 삐걱거리는 이유가 하스켈이 해결하지 못한 문제에서 샛길을 선택한 결과라고 생각함.


최근 본 것 중에 함수형을 얘기하면서 자연스럽게 하스켈을 예시로 들고 속 빈 강정 아니냐는 논지도 있던데 난 하스켈을 배우면서 얻은 게 있다고 확신함. 순수, 비순수 코드를 나누는 이유를 깨달은 거임. 난 이게 함수형에서 얻을 수 있는 교훈이라고 생각하고 있음.

근데 함수형 = 하스켈이란 생각을 가지고 함수형은 쓸모없다라는 생각을 하면 rescript나 다른 언어들이 아쉬울 것 같음.