Hacker News 의견

• 작성자는 "pipelining"이라고 부르지만, 올바른 용어는 "method chaining"이라고 생각함

  • Bash의 간단한 파이프라인과 비교: 각 구성 요소가 병렬로 실행되며 중간 결과가 스트리밍됨
  • Ruby에서는 각 줄이 순차적으로 처리되며 각 단계 사이에 완전한 배열이 생성됨
  • 디버깅이 어려워져서 요즘은 더 명시적인 코드를 작성함
  • 명시적인 코드는 보기에는 덜 깔끔하지만 중간 상태를 쉽게 검사할 수 있음

• 개인적으로 언어의 기능 세트를 작게 유지하고 빠르게 완성된 기능 세트를 달성하는 것을 지지함

  • 그러나 Elixir의 |> 문법을 모든 언어가 채택했으면 하는 바람이 있음

• Lisp 매크로는 체인된 컬렉션 연산자뿐만 아니라 호출 체인의 순서를 결정할 수 있는 일반적인 솔루션을 제공함

  • 예를 들어, (foo (bar (baz x)))를 (-> x baz bar foo)로 작성할 수 있음
  • 추가 인수가 있는 경우에도 처리 가능함
  • 자세한 내용은 Clojure의 스레딩 매크로 가이드 참조

• 이 용어를 유창한 인터페이스라고 배웠음. 파이프라이닝은 다른 것임

• 파이프라인 연산자는 부분 적용의 일종으로, 여러 인수를 바인딩하여 새로운 함수를 만들고 그 출력을 다른 함수에 전달할 수 있음

  • 부분 적용은 프로그램 작성에 매우 유용하며, 언젠가 (비-Haskell) 언어들이 이를 프로그램 구성의 기본으로 사용할 것임

• R의 tidyverse 사용자들은 이미 이를 사용하고 있음

• 파이프라이닝은 디버깅이 어려움. 예외 처리가 어려워 파이프라인에 분기를 추가해야 함

  • 파이프라인은 행복한 경로를 프로그래밍할 때만 유용함

• SQL 문법이 불필요하게 복잡함

  • SQL은 이미 연산자 언어지만 역사적 이유로 제약이 많음
  • 새로운 문법을 허용할 거라면 더 간단하게 작성할 수 있음
  • |> 문법은 표현력이 없고 시각적 잡음을 추가함

• 작성자는 "의미가 문법을 이긴다"고 주장하지만, 문법 선호에 초점을 맞추고 있음

  • 파이프라이닝은 체인이 길어질수록 디버깅이 어려워짐
  • Python에 대해 비판적이지만 구체적인 이유는 제시하지 않음
  • "pipelining"의 정의가 명확하지 않음

• effect-ts는 파이프라인과 명령형 코드를 모두 작성할 수 있게 해줌

  • 파이프라인 작성과 제너레이터 사용에 대한 문서 제공
  • 대부분의 커뮤니티가 명령형 스타일의 제너레이터를 선호하게 되었음
  • 디버깅과 유지보수가 더 쉬운 것으로 보임