C # vs F # 또는 F # vs C # 사용의 이점은 무엇입니까? [닫은]

저는 제품 배송보다 프로토 타이핑을 더 많이하는 기술 회사에서 일합니다. 방금 C #과 F #의 차이점이 무엇인지, MS가 F #을 만든 이유와 C #보다 더 나은 시나리오가 무엇인지 물었습니다.

나는 한동안이 언어를 사용해 왔으며 F #의 훌륭한 기능에 대해 쉽게 설명 할 수 있었기 때문에 C #에 대한 경험이 부족하여 다른 하나를 사용해야하는 이유를 말할 수 없습니다.

C # vs F # 또는 F # vs C # 사용의 이점은 무엇입니까?

명령형 언어에 비해 함수형 프로그래밍의 일반적인 이점 :

F #과 같은 함수형 프로그래밍 언어로 많은 문제를 훨씬 더 쉽게, 정의에 더 가깝고 간결하게 만들 수 있으며 코드는 오류 발생 가능성이 적습니다 (불변성, 더 강력한 유형 시스템, 직관적 인 재귀 알고리즘). 당신은 컴퓨터가 당신이 말하길 바라는 대신 당신이 의미하는 것을 코딩 할 수 있습니다 ;-) 당신이 그것을 구글하거나 심지어 그것을 검색 할 때 이와 같은 많은 토론을 발견 할 것입니다.

특별한 F # 장점 :

• 비동기 프로그래밍은 매우 쉽게 직관적 async {}-expressions - 심지어 ParallelFX와 함께 해당 C #을 -code 훨씬 더 큰

• 컴파일러 컴파일러 및 도메인 별 언어의 매우 쉬운 통합

• 필요에 따라 언어 확장 : LOP

• 측정 단위

• 더 유연한 구문

• 종종 더 짧고 우아한 솔루션

이 문서를 보세요

C #의 장점은 함수형 프로그래밍 언어보다 "명령형"응용 프로그램 (사용자 인터페이스, 명령형 알고리즘)에 더 정확하고, 사용하는 .NET 프레임 워크가 명령형으로 설계되었으며 더 널리 퍼져 있다는 것입니다.

또한 하나의 솔루션에 F #과 C #을 함께 사용할 수 있으므로 두 언어의 이점을 결합하여 필요한 곳에 사용할 수 있습니다.

드라이버보다 망치의 이점이 무엇인지 묻는 것과 같습니다. 매우 높은 수준에서는 둘 다 본질적으로 동일한 작업을 수행하지만 구현 수준에서는 달성하려는 작업에 맞는 최적의 도구를 선택하는 것이 중요합니다. C #에서는 어렵고 시간이 많이 걸리지 만 F #에서는 쉬운 작업이 있습니다. 스크루 드라이버로 못을 박는 것과 같습니다. 당신은 확실히 할 수 있습니다-그것은 이상적이지 않습니다.

데이터 조작은 내가 개인적으로 f #이 실제로 빛나고 C #이 잠재적으로 다루기 어려울 수있는 곳을 가리킬 수있는 한 가지 예입니다. 반대로 OO (c #)에서 복잡한 상태 저장 UI가 기능적 (f #)보다 더 쉽다고 (일반적으로 말하면) 말하고 싶습니다. (아마 바로 지금의 "쿨"이후이 동의하지 않는 사람들이있을 것 "증명"은 어떻게하는 것이 얼마나 쉬운 아무것도 F에 #을,하지만 난 그것에 의해 서). 수많은 다른 것들이 있습니다.

• F #은 수학에서 C #보다 성능이 우수합니다.
• C #을 사용하여 동일한 솔루션에서 F # 프로젝트를 사용할 수 있습니다 (그리고 서로 호출).
• F #은 복잡한 알고리즘 프로그래밍, 금융 및 과학 응용 프로그램에 정말 좋습니다.
• F #은 논리적으로 병렬 실행에 정말 좋습니다 (F # 코드를 C #보다 병렬 코어에서 실행하는 것이 더 쉽습니다).

내가 이해하는대로 질문에 답하려면 : 왜 C #을 사용합니까? (당신은 이미 F #에서 판매되었다고 말합니다.)

우선. 단순히 "기능적 대 OO"가 아닙니다. "기능 + OO 대 OO"입니다. C #의 기능적 기능은 매우 초보적입니다. F #은 그렇지 않습니다. 한편 F #은 C #의 거의 모든 OO 기능을 수행합니다. 대부분의 경우 F #은 C # 기능의 상위 집합으로 끝납니다.

그러나 F #이 최선의 선택이 아닐 수있는 몇 가지 경우가 있습니다.

• Interop. F #에서 너무 편하지 않은 라이브러리가 많이 있습니다. F #이 똑같이하지 않는 특정 C # OO를 악용하거나 C # 컴파일러의 내부에 의존 할 수 있습니다. 예를 들어, Expression. F # 인용문을 식으로 쉽게 변환 할 수 있지만 결과가 항상 C #에서 생성되는 것과 정확히 일치하지는 않습니다. 특정 라이브러리에는이 문제가 있습니다.

  • 예, interop은 꽤 큰 네트워크이며 일부 라이브러리와 약간의 마찰을 일으킬 수 있습니다.

  • 기존 코드베이스가 큰 경우 interop도 포함 할 것을 고려합니다. F #으로 파트 작성을 시작하는 것은 이치에 맞지 않을 수 있습니다.

• 디자인 도구. F #에는 아무것도 없습니다. 그것이 아무것도 가질 수 없다는 의미는 아니지만 지금 당장은 F # 코드 숨김으로 WinForms 앱을 만들 수 없습니다. ASPX 페이지와 같이 지원되는 경우에도 현재 IntelliSense를 사용할 수 없습니다. 따라서 생성 된 코드의 경계가 어디에 있는지 신중하게 고려해야합니다. 다양한 디자이너를 거의 독점적으로 사용하는 아주 작은 프로젝트에서 "접착제"또는 논리에 F #을 사용하는 것은 가치가 없을 수 있습니다. 규모가 큰 프로젝트에서는 문제가되지 않을 수 있습니다.

  • 이것은 본질적인 문제가 아닙니다. Rex M의 답변과 달리, 많은 변경 가능한 필드가있는 UI를 더 잘 수행하도록 만드는 C # 또는 F #에 대한 본질적인 요소는 없습니다. 아마도 그는 "변경 가능"을 작성하고 = 대신 <-를 사용하는 추가 오버 헤드를 언급하고 있었을 것입니다.

  • 또한 사용 된 라이브러리 / 디자이너에 따라 다릅니다. 우리는 모든 컨트롤러에 대해 F #과 함께 ASP.NET MVC를 사용하고 ASPX 디자이너를 얻기 위해 C # 웹 프로젝트를 사용하는 것을 좋아합니다. 해당 페이지에서 필요한 내용에 따라 C #과 F #간에 실제 ASPX "코드 인라인"을 혼합합니다. (IntelliSense 대 F # 유형.)

• 기타 도구. C # 만 기대하고 F # 프로젝트 나 컴파일 된 코드를 처리하는 방법을 모를 수 있습니다. 또한 F #의 라이브러리는 .NET의 일부로 제공되지 않으므로 추가로 제공해야합니다.

• 하지만 가장 중요한 문제는 무엇입니까? 사람들. 개발자 중 누구도 F #을 배우고 싶지 않거나 더 나쁜 경우 특정 측면을 이해하는 데 심각한 어려움을 겪고 있다면 건배 일 것입니다. (그런 경우에도 어쨌든 건배한다고 주장합니다.) 아, 그리고 경영진이 거절하면 문제가 될 수 있습니다.

나는 이것에 대해 얼마 전에 썼다 : Why NOT F #?

절차 적 언어와 함수형 언어의 비교를 요청하고 있으므로 여기에서 질문에 답할 수 있다고 생각합니다. 절차 적 프로그래밍과 함수형 프로그래밍의 차이점은 무엇입니까?

MS가 F #을 만든 이유에 대한 대답은 간단합니다. .Net 라이브러리에 액세스 할 수있는 기능적 언어를 만드는 것은 단순히 시장 기반을 확장했습니다. 그리고 구문이 OCaml과 거의 동일하다는 것을 보았을 때 실제로 많은 노력이 필요하지 않았습니다.

F #은 C #, C ++, VB와 비교한다면 아직 또 다른 프로그래밍 언어가 아닙니다. C #, C, VB는 모두 명령형 또는 절차 적 프로그래밍 언어입니다. F #은 함수형 프로그래밍 언어입니다.

명령형 언어에 비해 함수형 프로그래밍 언어의 두 가지 주요 이점은 1. 부작용이 없다는 것입니다. 이것은 프로그램의 속성에 대한 수학적 추론을 훨씬 쉽게 만듭니다. 2. 기능은 일류 시민입니다. 다른 값처럼 쉽게 다른 함수에 매개 변수로 함수를 전달할 수 있습니다.

명령형 및 함수형 프로그래밍 언어 모두 용도가 있습니다. 아직 F #에서 심각한 작업을 수행하지는 않았지만 현재 C # 기반 제품 중 하나에서 스케줄링 구성 요소를 구현하고 있으며 동일한 스케줄러를 F #으로 코딩하여 실험을 수행하여 구현은 C #에 해당하는 것보다 더 쉽게 검증 할 수 있습니다.

F #은 기본적으로 함수형 프로그래밍 언어의 C ++입니다. 그들은 정말 어리석은 부분을 포함하여 Objective Caml에서 거의 모든 것을 유지하고 .NET에서 모든 나쁜 것들을 가져 오는 방식으로 .NET 런타임 위에 던졌습니다.

예를 들어, Objective Caml을 사용하면 하나의 null 유형 인 <T> 옵션이 제공됩니다. F #을 사용하면 세 가지 유형의 null, option <T>, Nullable <T> 및 참조 null이 제공됩니다. 즉, "None"인지 먼저 확인해야하는 옵션이있는 경우 "Some (null)"인지 확인해야합니다.

F #은 예전의 자바 클론 J #과 같으며 단지 관심을 끌기위한 멍청한 언어입니다. 어떤 사람들은 그것을 좋아할 것이고, 몇몇 사람들은 그것을 사용할 것입니다. 그러나 결국 그것은 여전히 ​​CLR에 붙은 20 년 된 언어입니다.

내가 가장 좋아하는 .NET의 측면 중 하나는 제네릭입니다. F #으로 절차 코드를 작성하더라도 형식 유추의 이점을 계속 누릴 수 있습니다. 일반 코드를 쉽게 작성할 수 있습니다.

C #에서는 기본적으로 구체적인 코드를 작성하고 일반 코드를 작성하려면 추가 작업을해야합니다.

F #에서는 기본적으로 일반 코드를 작성합니다. F #과 C #에서 1 년 넘게 프로그래밍을 한 후, F #으로 작성한 라이브러리 코드가 C #으로 작성한 코드보다 더 간결하고 일반적이므로 재사용 가능성이 더 높다는 것을 알게되었습니다. 필자는 필수 형식 주석에 눈이 멀었 기 때문에 C #으로 제네릭 코드를 작성할 수있는 많은 기회를 놓친다.

그러나 취향과 프로그래밍 스타일에 따라 C #을 사용하는 것이 바람직한 상황이 있습니다.

• C #은 형식간에 선언 순서를 부과하지 않으며 파일이 컴파일되는 순서에 민감하지 않습니다.
• C #에는 형식 유추로 인해 F #에서 감당할 수없는 일부 암시 적 변환이 있습니다.