F# 기능 C#은 절대 얻을 수 없습니다.

4838 단어 csharpdotnetfsharp
C#은 변경 가능한 엔터티와 달리 값 및 데이터 변환을 사용하여 프로그래밍을 가능하게 하는 데 큰 발전을 이루었습니다. C#은 일반적으로 변경 가능성을 수용하지만 해당 레코드는 변경할 수 없습니다. 그들의 간결한 구문은 원시적인 집착에 대한 모든 주장을 제거합니다. 스위치 표현식 및 패턴 일치를 사용하면 명령형 논리가 아닌 표현식 체인으로 더 많은 논리를 표현할 수 있습니다. 눈 속에서 피어나는 이른 봄 꽃처럼 클래스가 없는 Program.cs 또는 ASP.NET Minimal API를 사용하면 클래스에서 벗어날 수 있는 매력도 있습니다. C# 컴파일러 팀은 결국 기본 생성자와 구별된 공용체를 추가하기로 결정한 것 같습니다. C#이 완전한 대수 데이터 유형 지원을 받을 예정인 경우 다음과 같은 질문을 해야 합니다. F#이 계속 관련성이 있습니까?

C#은 의심할 여지 없이 점점 더 많은 기능을 제공하지만 C 언어 계열(C, C++, Java, JavaScript)에 뿌리를 두고 있기 때문에 내 생각에는 항상 C#에서 코드를 작성하는 경험을 다소 어렵게 만들 것입니다. F#은 계속해서 훨씬 더 간결하고 유연하며 완벽하게 객관적이고 재미있을 것입니다.
다음은 C#에 없을 것 같은 몇 가지 F# 기능입니다.

1) 카레 기능



커리 함수는 부분 적용을 가능하게 합니다. enables dependency injection without objects . C#은 개체 지향에서 몇 단계 뒤로 물러나지만 개체 기반을 유지해야 합니다. 반대로 F#은 함수나 개체를 사용하여 프로그래밍할 수 있는 유연성을 제공합니다. 둘 다 강력합니다. C#에서 커리 함수를 작성하는 것이 가능하지만 언어 지원 및 형식 유추가 없기 때문에 비실용적입니다. 내가 아는 한 커뮤니티에서 이 기능에 대한 관심이 없기 때문에 C#에서는 이 기능을 절대 볼 수 없을 것입니다.

// Wait what?
Func<T, Func<U, Func<V, TResult>>> CurriedFunction(...


2) 전역 유형 추론



F#은 완전한 Hindley-Milner 유형 유추 기능을 제공하므로 어려운 유형 서명을 철자하는 번거로움 없이 기능적인 스타일로 작성할 수 있습니다. 또한 F# 프로그램이 C#에 상응하는 것보다 훨씬 더 간결해지는 데 크게 기여합니다. 이는 F#의 식 기반 특성에 크게 의존합니다. 표현식에는 유형이 있습니다. 진술은 하지 않습니다. C#은 형식 유추를 약간 개선할 수 있지만 인수 형식이나 반환 형식을 유추할 가능성은 거의 없습니다.

3) 자동 일반화



F#은 형식 유추를 수행할 때 가능한 한 제네릭 함수 시그니처를 제시하려고 합니다. C#은 함수 시그니처를 유추하지 않으며 유추할 수도 없기 때문에 이 작업도 수행할 수 없습니다.

4) 기본적으로 모든 곳에서 일관되게 불변성



F#은 기본적으로 모든 곳에서 불변으로 설정되어 있습니다. let 바인딩, 함수 인수, 생성자 인수, 클래스 필드뿐 아니라 기본 컬렉션 유형: List , Seq , Set , Map 는 불변입니다. Array는 아니지만(단지 .NET 배열임) Array 모듈은 복사 및 업데이트 작업에 크게 의존합니다.
C#은 레코드를 변경할 수 없지만 튜플을 변경할 수 있고 사전에 기록된 모든 항목을 변경할 수 있으므로 결정적으로 결정되지 않은 것 같습니다. 불변 컬렉션이 존재하지만( System.Collections.Immutable ), 언어 지원이 부족하고( ImmutableArray<T>.Empty vs new T[0] ) 놀랍게도 값 평등을 제공하지 않습니다.

5) 파이프 포워드 연산자



너무 많은 C# 코드는

var thing = GetThing();
var propertyOfThing = thing.GetProperty() ?? thatOtherThing;
var transformedThing = Transform(propertyOfThing);
// etc.


명명된 변수를 추가하는 것이 명확성을 높이는 데 도움이 될 수 있지만, 사실을 직시합시다. 변환의 긴 체인이 단일 표현식으로 보기에 좋지 않기 때문에 여기에 추가되었습니다. Transform(GetThing().GetProperty() ?? ... 가독성이 좋지 않습니다. 여러 줄에 걸쳐 흩어져 있어도 논리가 때로는 왼쪽에서 오른쪽으로( thing.GetProperty() ?? thatOtherThing ) 때로는 오른쪽에서 왼쪽으로 흐릅니다( Transform(propertyOfThing) ). F# 파이프 연산자는 이 모든 것을 수정합니다.
  • 사소한 변수 이름이 필요하지 않습니다.
  • 우리가 자연스럽게 텍스트를 읽는 방식으로 논리가 왼쪽에서 오른쪽으로, 위에서 아래로 흐르도록 합니다.
  • 자유 기능을 촉진합니다.

  • let thing = GetThing()
    thing.GetProperty()
    |> Option.defaultValue thatOtherThing
    |> Transform
    |> etc.
    


    C#이 제공하는 가장 가까운 것은 유창한 API입니다.

    이제 이것은 이론적으로 C#에서 발생할 수 있습니다. it has actually been discussed for a long a time . F#보다 C#에 훨씬 가까운 언어인 JavaScript는 이를 매우 심각하게 고려하고 있습니다(tc39 참조). 그러나 나는 오랫동안 이런 일이 일어날 것이라고 기대하지 않을 것입니다.

    좋은 웹페이지 즐겨찾기