Functional Programming

함수형 사고에 대해서 살펴보기 예시

: 어떤 사람과(Person) 거주 국가가 같은 사람을 전부 찾고, 어떤 학생과 거주 국가와 다니는 학교가 모두 같은 학생을 전부 찾기위에 함수를 함수형으로 바꾸면(기능만)위와 같이 바꿀 수 있고, 이 함수는 유연하게 성이 같고, 학교가 같은 함수로 쉽게 기능을 추가할

Lodash와 함수형 프로그래밍 이름은 거창하지만 별건 아니다.. 단지 함수형 프로그래밍을 할 때 유용한 라이브러리인 lodash가 제공하는 함수들을 바탕으로 함수형 프로그래밍을 좀 더 이해해보고자 글을 쓴다. _.chain 을 통한 지연 평가 위와 같이 각각의

: 위의 명제(?)는 아니지만, 문장을 위해서 튜플 이라는 자료 구조를 사용하고자 한다. 튜플은 형식이 다른 원소를 한 데 묶어서 다른 함수에 건네주는 일이 가능한 불변적인 자료구조이다. 물론, 배열이나 객체를 이용할 수 있지만, 튜플을 사용하면 좀 더 쉽게 '불변성'

일단 바로는 이해 안되겠지만, 함수형 프로그래밍의 진짜 목표는 애플리케이션의 부수효과를 방지하고, 상태 변이를 감소하기 위해 데이터의 제어 흐름과 연산을 추상하는 것이다.부수효과상태 변이 감소데이터의 제어 흐름과 연산 추상솔직히 아직 뭔소리인지 잘모르겠지만, 일단 이정

위의 코드를 바탕으로 분석해보면(나만의 관점)객체 지향 설계는 특정 객체의 데이터 설계에 종속적으로 메서드를 만들어야 한다. 예를 들어, school 정보는 Student에 있고, 나머지 정보는 Person에 있는 상황에서 studentsInSameCountryAndS

: React와 Redux 등을 쓰면서 불변성에 대해서는 익히 들어서 알고 있었다. 하지만, 생각해보면 왜 불변성을 유지해야하지? 라는 생각을 제대로 해본 적이 없다. 단지 React, Redux 등의 인터페이스가 불변성을 유지하는 방향으로 이뤄져있기 때문에 거기에 맞

책을 통해 함수형 프로그래밍을 공부하는 도중에 위와 같은 주제가 나왔어서, 그럼 실제로 두개의 기법을 모두 활용한다면 어떤 형태일까? 가 궁금했다.객체지향 프로그래밍의 장점 및 필요성계층적 데이터를 처리할 필요가 있을 때실무에서 레거시 객체와 상호작용할 떄실세계 문제를

위와 같은 코드를 아래와 같이 바꿨다. 완벽하게 선언형으로 컨버팅하진 못했지만, 그래도 훨씬 깔끔하고, 가독성 있는 코드로 바꿀 수 있었다. 앞으로 최대한 이렇게 선언형 프로그램이 방식으로 사고하는 버릇을 들이자.

: 재귀(Recursion)란 주어진 문제를 자기 반복적인 문제들로 잘게 분해한 다음에 이들을 다시 조합해서 원래 문제의 정답을 찾는 기법이다. 재귀의 주된 구성 요소는기저 케이스(=종료 조건)재귀 케이스이다.: 너무 복잡하게 접근하기보다는 딱 떠오르는 것에 비유를 해

부분 적용과 커링을 비교해보자 What's the difference between them ? 커링 : 일단 Currying or curry는 내가 평소에 자주 쓰는 스킬이기도 하다. 하지만, 이번에 부분 적용에 대해 제대로 이해하면서 내가 결국 부분 적용을 쓰고

위의 pipe 툴을 이용해서 함수들을 합성해본다. compose와 달리 pipe는 나의 직관과 일치하는데, 앞에서부터 차례로 실행하고, return 값을 뒤의 함수의 매개변수에 넣는다. 여기에서 좀 더 간결한 로직을 만들 수 있도록 앞에서 튜플 등의 자료구조를 배웠던

함수 조합기에 대해서 알아보자 의문점 : if-else 이런거 안쓰는게 함수형에서는 지향하는 바인 것은 알겠는데 그럼 pipe, curry, partial 이런걸로만 세세한 처리를 한다는건가 ? 함수 조합기(Function Combinator) : 조합기란 함수 또는

null 참조는 (...) 10억 달러짜리 실수다. by 찰스 앤터니 리처드 호어일단 개념에 얽매이지 말고, 이게 왜 필요할까 그리고 실질적인 사용 예시로서 생각해보면 Maybe, Either 이런걸 뭘 위해 사용할까? 라는 측면에서 접근해보자. 함수형 프로그래밍의 핵

객체 지향형으로 프로그래밍을 하다보면 관심사의 분리 혹은 그 세계관을 각각의 객체로 정리해서 쓰기 때문에 뭐가 필요할 때 그 세계관 별로 찾아쓰기 좋음. 그런 모델링이 명확하게 구축돼 있으면 기획이 좀 더 뚜렷하게 분리돼 구현되는 느낌이 있음.클래스 안에 프로퍼티 등의

: 타입 지정하는게(any를 안쓰면) 너무 어렵다…그렇다고 fp-ts 등의 라이브러리를 쓰자니 내가 여태까지 쓰던 인터페이스가 아니라 처음부터 다시 배워야하는 상황이라 당황스럽다.. 아무래도 러닝커브가 있더라도 새로운 인터페이스에 적응하는 편이 빠를 것 같긴하다(any

\-> 지난번에 OOP, FP를 비교해보면서 셀프 과제로 각각의 코딩 방식으로 유효성 검사가 섞은 회원가입 폼을 만들어보기로 했었는데 아직 완성은 아니지만, 함수형 프로그래밍 + react hook 방식을 섞어서 1차 완성을 해봤다(아직 태그 부분은 미적용)아직은 이게

: 지난번 포스팅에 이어서 작업을 해보았다. 꽤나 많은 부분이 변화했는데, 크게 변화시킨 부분은모든 로직을 단일 함수 조각으로 쪼갰고, 그 쪼갠 함수들을 최근에 배운 함수 조합기와 curry, pipe 등 원래 쓰던 함수형 프로그래밍 패턴을 더해서 합성하는 식으로 변경

: 사실 아직 IO 모나드의 실질적인 쓰임새?를 잘 모르겠다. 내가 Pipe와 Compose에 익숙해져서 굳이 이게 Pipe와 Compose와 뭐가 다른가 싶긴하지만, 결론적으로 단지 함수형 프로그래밍의 두가지 방법론인 함수의 합성과 체이닝 이 두가지 방법론에 따라 P

: 함수형 프로그래밍을 하는데 있어서 여태까지 '최적화'라는 측면에서 살펴본적은 없다. FP를 할 때 데이터 흐름을 함수형 세계관으로 관리하기 위해서 모나드, 체이닝을 쓰고, 프로그램 로직 흐름을 컨트롤하기 위해서 합성을 이용하며 이를 표현하기 위한 툴들을 주로 알아봤

: 여태까지 배웠던 모나드들은(Maybe, Either, IO) 모두 한가지 목표를 모나드 안에서 커버하는 방식으로 쓰여졌다. 예를 들어, null, undefined 등을 필터링하기 위해 썼던 Maybe 모나드, 에러 메시지까지 출력하기 위해 썼던 Either 모나드