함수형 프로그래밍

https://spectrum.ieee.org/functional-programming

Why Functional Programming Should Be the Future of Software Development

https://news.hada.io/topic?id=7725 

함수형 프로그래밍이 소프트웨어 개발의 미래가 되어야 하는 이유 | GeekNews

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

https://medium.com/@jooyunghan/%ED%95%A8%EC%88%98%ED%98%95-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-fab4e960d263

 

(번역) 함수형 프로그래밍이란 무엇인가?

모든 입력이 입력으로 선언되고 (숨겨진 것이 없어야 한다) 마찬가지로 모든 출력이 출력으로 선언된 함수를 ‘순수(pure)’하다고 부른다. 함수형 프로그래밍은 순수 함수를 작성하는 것, 그러니까 숨겨진 입력이나 출력을 최대한 제거하여 가능한한 우리 코드의 대부분이 단지 입력과 출력의 관계를 기술하게끔 하는 것을 말한다.

부작용을 완전히 피할 수는 없다. 대부분의 프로그램은 반환 값을 얻기 위해서가 아니라 어떤 동작을 하기 위해 실행하기 때문이다. 하지만 프로그램 내부에서는 엄격하게 통제하고자 한다. 우리는 가능한 모든 곳에서 부작용(과 부원인)을 제거하고, 또 제거할 수 없는 경우에는 철저하게 통제할 것이다.

다르게 말하자면, 코드 조각이 필요로 하는 것과 유발하게 될 결과를 숨기지 말자. 코드 조각이 제대로 실행하기 위해 뭔가를 필요로 한다면 그렇게 말하자. 뭔가 유용한 일을 한다면 출력 형태로 선언하자. 이렇게 한다면 우리의 코드는 더 명확해 질 것이다. 복잡성이 표면에 드러나고 우리는 그것을 분해하여 처리할 수 있을 것이다.

 

더 구체적으로 말하자면, 함수형 언어는 여러분이 가능한한 부작용을 제거하고 그렇지 않은 곳에는 철저히 제어 할 수 있도록 적극적으로 도와주는 언어이다.

더 극적으로 표현하자면, 함수형 언어는 더 적극적이고 더 격렬하게 부작용에 적대적인 언어이다. 부작용은 복잡성이고, 복잡성은 버그이며, 버그는 악마이다. 함수형 언어는 여러분들도 부작용에 적대적이 되도록 도와줄 것이다. 여러분과 함께 그들(부작용,복잡성,버그)을 깨부시고 굴복시킬 것이다.

 

https://medium.com/@jooyunghan/%EC%96%B4%EB%96%A4-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%96%B8%EC%96%B4%EB%93%A4%EC%9D%B4-%ED%95%A8%EC%88%98%ED%98%95%EC%9D%B8%EA%B0%80-fec1e941c47f

(번역) 어떤 프로그래밍 언어들이 함수형인가?

 

함수형 언어는 여러분이 부작용을 제거할 수 있는 곳에서는 제거를 돕고, 그럴수 없는 곳에서는 통제할 수 있게 도와준다.

자바스크립트는 함수형 프로그래밍 언어가 아니다

함수형 언어는 여러분이 부작용을 제거할 수 있는 곳에서는 제거를 돕고, 그럴수 없는 곳에서는 통제할 수 있게 도와준다. 자바스크립트는 이 기준을 만족하지 않는다. 사실 자바스크립트가 적극적으로 부작용을 장려하는 것은 쉽게 찾을 수 있다.

가장 쉽게 찾을 수 있는 것이 바로 this이다. this는 모든 함수의 숨겨진 입력이다. 특히 this가 마법처럼 보이는 까닭은 의미 변화가 자유롭기 때문이다. 심지어 전문가라고 할만한 자바스크립트 프로그래머들조차 this의 참조 대상을 추적하는데 어려움을 겪는다. 함수형 관점에서 보자면 어디서나 마법처럼 접근 가능하다는 사실이 설계 결함의 징후(design smell)이다.

 

자바는 함수형 프로그래밍 언어가 아니다

자바는 확실히 함수형 언어가 아니다. 자바 1.8에서 람다가 추가되었다고 바뀌는 것은 없다. 자바는 함수형 프로그래밍과 정반대 지점에 있다. 자바의 핵심 설계 원칙에서 말하는 것이 바로 “코드는 지역화된 부작용들 — 즉 객체의 지역 상태를 변경하거나 지역 상태에 의존하는 메쏘드들 — 로 조직화되어야 한다”이다.

사실, 자바는 함수형 프로그래밍에 적대적이다. 여러분이 자바 코드를 작성하면서 부작용 없게, 즉 로컬 객체 상태를 읽거나 변경하지 않게 작성한다면, 여러분은 “나쁜 프로그래머”라고 불리게 될 것이다. 자바는 원래 그런 식으로 작성하지 않기 때문이다. 여러분이 작성한 부작용 없는 코드는 static 키워드로 점철될테고 여러분은 잔뜩 화가난 동료들에 의해 자바 동네에서 쫓겨날 것이다.

자바가 틀렸다는 말을 하려는게 아니다. (음, 좋다. 그걸 부정하지는 않겠다) 요지는 부작용에 대해 완전히 다른 관점을 가지고 있다는 점이다. 자바는 부작용을 국소화하는 것을 좋은 코드의 초석이라고 보며, FP는 부작용을 악으로 간주한다.

여러분은 조금 다른 각도에서 볼 수도 있다. 자바나 FP나 부작용의 문제에 대한 응답이라고 볼 수 있다. 두 가지 모델 모두 부작용을 문제라고 인식하는 것은 같지만 반응이 다를 뿐이다. OO의 대답은 “부작용을 ‘객체’라는 경계에 가두어라”이고, 반면 FP의 대답은 “부작용을 제거하라”이다. 안타깝게도 사실상 자바는 부작용을 캡슐화하려는 시도를 전혀 하지 않으며 오히려 그것을 필수화한다. 상태를 가진 객체라는 형태로 부작용을 만들지 않는다면 여러분은 “나쁜 자바 프로그래머”일 뿐이다. 실제로 static을 너무 자주 사용한다고 해고되는 경우도 있다.

 

https://search.shopping.naver.com/book/catalog/32467591621

쏙쏙 들어오는 함수형 코딩 : 네이버 도서

 

 

+ 함수형 언어에 대해 찾아보면서 좋은 글도 함께 발견했다

https://medium.com/@jooyunghan/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%B8%ED%84%B0%EB%B7%B0-d0062ab9aa03

개발자 인터뷰