36P by xguru 28일전 | favorite | 댓글 14개
  • "함수형 프로그래밍(FP)은 배우기 어렵지만 당신의 코드가 불쾌한 놀라움을 덜 만들게 될 것"
  • FP에서는 "less is more"
  • (Maybe/Option 으로) Null Reference 문제를 해결
  • FP는 학습 곡선이 가파르다
  • FP의 미래
    • 적은 수의 개발자로 더 많은 개발을 하려면 가능한 모든 도구를 사용해야 하는데, FP는 이를 위한 티켓임
    • 우리 같이 화려하지 않은 회사들은 개발자 채용이 어려움. 하지만 FP 코드베이스에서 일하고 싶어하는 탑 티어 개발자를 채용하는게 가능해짐
    • FP를 채택하면 품질과 견고성이 향상되고, FP에서는 생기지 않는 버그에 들이는 시간이 줄어들 것
    • FP의 기능들이 주류 언어에서 점점 보이기 시작하는 것은 소프트웨어 업계가 패러다임 시프트를 준비하고 있다는 것.
    • 업계가 완벽히 전환하게 되기까지는 많은 작업이 필요하겠지만, 이렇게 하는 이점이 분명하기 때문에 어디로 가는 지에 대해서는 의심할 바 없음

물론 함수형 프로그래밍도 좋은 방법이라고 생각은 하지만, 그 장점을 설득력있게 전달 해주는 사람은 잘 없는것 같습니다. 그냥 좋다고 하면 잘 와닿지 않잖아요?

이하 개인적인 의견으로, 그리고 현대의 모든 프로그램은 사실상 튜링 기계 기반으로 이뤄져 있기에, 추상적으로 크게 함수와 자료로 나눌 수 있고, 때문에 절차적 프로그래밍도 근원적으로는 함수형 이라고 생각합니다. 그럼 함수형의 절차형 대비 진짜 장점은 무엇인가하면, 그냥 '전역 혹은 그에 준하는 영역의 변수 안쓰기'라고 생각됩니다. 이 장점으로 인해 '함수와 함수간의 격리' 및 '멀티쓰레드 컴퓨팅'에도 효율적이죠.

하지만 이건 함수형 프로그래밍으로만 얻을 수 있는 잇점이냐면 그건 아닙니다. 절차형 언어에서도 dependency injection 개념을 통해 클래스 및 함수 단위 격리가 권장되고 (이미 모던한 프레임워크는 모두 기본 차용하고 있죠), rust언어에서는 언어적인 제한으로 편리한 동시성 컴퓨팅을 추구 할 수 있게 해놓았죠.

정리하면 함수형 언어는 좋은 언어이고 방법론이지만, '진화적 의미에서 우월'이라기 보다 그저 go나 rust 언어 처럼 '실패할 가능성을 언어 단위에서 배제하기 위해 노력했으면서, 사용하기 어려운 언어'라고 생각합니다.

절차언어에서도 함수 합성 같은게 가능하다는 말씀이실까요?

'합수 합성'의 정의를 좁게 보면 함수형 언어에서만 된다고 생각할 수 있겠지만, 가만 생각해보면 그 실행도 어차피 절차언어인 기계어나 어셈블리어 위에서 돌아가잖아요. 즉 '가능, 불가능'의 문제가 아니라, '언어의 관심사, 취향, 철학'의 문제입니다. '함수 합성'의 정의를 좁게 '특정 언어의 특정 기능'이 아닌 '논리적 기능 간 합성'으로 넓게보면 얼마든지 가능하죠. 그리고 분명히 함수형 언어의 장점은 존재하기에 이를 적극적으로 차용한게 rxjs나 spark 같은것들이구요.

다들 컴과에서 배웠듯이 아래는 같은 결과지만, 단지 표현형이 다를 뿐입니다. 그리고 전위는 함수형이라고 부르는 경우가 많죠.

전위표기법 : + 1 1
중위표기법 : 1 + 1
후위표기법 : 1 1 +

인간의 사고와 업무를 순수 함수형 프로그래밍 언어들처럼 완벽히 수식화하는게 어렵죠. free monad 이런거 보면 그냥 rxjs 정도까지가 최대 허용범위인듯
. Fp도 배보다 배꼽이 커지는 순간이 옵니다.
기존 fp 효과도 데이터와 메서드를 분리한 정도지,
옵셔널이 생각보다 잘 안쓰이는것만봐도 타입 추상은 불필요한 추상화임(타입 맞추느라 생산성을 넘깎아먹음).
클로저마냥 데이터와 연산을 더 추상화하는 방향이 아닌이상 기존언어를 활용하기엔 한계가있음

학습곡선이 높은게 맞는 것 같습니다 댓글에서도 진정 함수형 프로그래밍을 완전히 모르시는 내용이 있네요 물론 잘아시고 쓴 댓글도 있네요 함수형 힘듭니다 저도 아직도 공부중입니다 ㅜ ㅜ

프로그래밍 언어가 더 이상 개발팀의 취향이 아니라 회사의 생존의 문제가 되는 케이스가 생길 때 비로소 우리는 FP의 필요성에 대해 다시 얘기해볼 수 있을겁니다.

제가 정리하겠습니다. 메모리 관리와 일부 알고라즘에서 아직 객체지향을 뛰어넘지 못하고 있습니다. 상황과 비용에 따라 적절히 사용하면 됩니다.

음.. 학습 곡선이 가파르다는 주장에는 동의하지 못하겠고

일단 그냥 쉽고, 실수할 여지가 줄어들고, 따라서 생산성이 높아집니다.
그거면 됐죠 뭐

함수형 프로그래밍의 장점이라고 주장하는 것들 보면
대부분 불변성의 장점들을 얘기하더라구요

그냥 객체지향에 불변성을 적극 도입하면 되는 것 아닌가요?

불변성은 함수형 프로그래밍 패러다임에서 자주 쓰는 도구일 뿐입니다.
제가 아는 한, 함수형 프로그래밍 패러다임은 ‘부수 효과’(Side effect) 를 최대한 통제하고자 하는 프로그래밍 패러다임입니다.
부수 효과를 통제하려다 보니 자연스레 참조 투명성이라던가 불변성, 순수 함수 같은 것을 중시하는 것으로 알고 있습니다.

그런 점에서, 굳이 함수형 프로그래밍 언어를 쓰지 않더라도 자신이 작성하는 함수나 메소드의 부수 효과에 대해 명확히 인지하고 이를 적절히 통제할 수 있도록 하는 것이 바람직하다고 생각합니다. 이는 코드에서 나는 악취(Code smell)를 줄이고, 단위 테스트를 작성하는 것도 수월해지는 등 장점이 많습니다.

여기에 관해 좀 더 자세히 설명한 번역 글도 있습니다.

이와 같은 관점에서 부수 효과를 최소화하는 리팩토링에 집중하는 서적으로는 쏙쏙 들어오는 함수형 코딩: 심플한 코드로 복잡한 소프트웨어 길들이기가 있습니다. 이론보다는 실용적이고 실무적인 관점에서 접근하기 때문에, 좋은 코드를 작성하고 싶은 사람이라면 충분히 읽고 익힐 만한 가치가 있습니다. 이걸 읽고 나서 코드 작성하면서 부수 효과에 관해 이전보다 훨씬 신경쓰게 되기만 해도 책값 정도는 충분히 하는 책이라 생각합니다.

감사합니다 찾아서 읽어봐야겠네요.

아! 번역서가 나왔었군요! 읽어봐야겠습니다!

책 추천 감사합니다!! 바로 사서 읽어보겠습니다!

저 책 정말 좋더라구요!
리팩토링 관점에서 보는게 정말 쓰기도 편하구요