Jakie są zalety używania języka C # w porównaniu z F # lub F # w porównaniu z C #? [Zamknięte]

Pracuję dla firmy technologicznej, która zajmuje się bardziej prototypowaniem niż wysyłką produktów. Właśnie zostałem zapytany, jaka jest różnica między C # i F #, dlaczego MS utworzył F # i jakie scenariusze byłyby lepsze niż C #.

Używam tego języka już od jakiegoś czasu i uwielbiam go, więc z łatwością mogłem mówić o wspaniałych funkcjach F #, jednak brakuje mi doświadczenia w C #, aby powiedzieć, dlaczego powinniśmy używać jednego nad drugim.

Jakie są zalety używania języka C # w porównaniu z F # lub F # w porównaniu z C #?

Ogólne zalety programowania funkcyjnego w porównaniu z językami imperatywnymi:

Możesz sformułować wiele problemów znacznie łatwiej, bliżej ich definicji i bardziej zwięźle w funkcjonalnym języku programowania, takim jak F #, a Twój kod jest mniej podatny na błędy (niezmienność, mocniejszy system typów, intuicyjne algorytmy rekurencyjne). Możesz zakodować to, co masz na myśli, zamiast tego, co komputer chce, żebyś powiedział ;-) Znajdziesz wiele takich dyskusji, kiedy to wyszukasz w Google lub nawet wyszukasz w SO.

Specjalne zalety języka F #:

• Programowanie asynchroniczne jest niezwykle łatwe i intuicyjne dzięki async {}-wyrażeniom - nawet w przypadku ParallelFX odpowiedni kod C # jest znacznie większy

• Bardzo łatwa integracja kompilatorów kompilatorów i języków specyficznych dla domeny

• Rozszerzanie języka według potrzeb: LOP

• Jednostki miary

• Bardziej elastyczna składnia

• Często krótsze i bardziej eleganckie rozwiązania

Spójrz na ten dokument

Zaletą języka C # jest to, że jest on często dokładniejszy w zastosowaniach „imperatywnych” (interfejs użytkownika, algorytmy imperatywne) niż funkcjonalny język programowania, a platforma .NET Framework, której używa, jest zaprojektowana w sposób imperatywny i że jest bardziej rozpowszechniona.

Co więcej, możesz mieć F # i C # razem w jednym rozwiązaniu, dzięki czemu możesz połączyć zalety obu języków i używać ich tam, gdzie są potrzebne.

To tak, jakby zapytać, jaką korzyść ma młotek nad śrubokrętem. Na bardzo wysokim poziomie oba robią zasadniczo to samo, ale na poziomie implementacji ważne jest, aby wybrać optymalne narzędzie do tego, co próbujesz osiągnąć. Są zadania, które są trudne i czasochłonne w języku c #, ale łatwe w języku f # - jak próba wbicia gwóźdź śrubokrętem. Na pewno możesz to zrobić - to po prostu nie jest idealne.

Manipulacja danymi jest jednym z przykładów, które osobiście mogę wskazać, gdzie f # naprawdę świeci, a c # może być potencjalnie nieporęczny. Z drugiej strony powiedziałbym (ogólnie), że złożony stanowy interfejs użytkownika jest łatwiejszy w OO (c #) niż funkcjonalnym (f #). (Prawdopodobnie byliby ludzie, którzy się z tym nie zgadzają, ponieważ "fajnie" jest teraz "udowodnić", jak łatwo jest zrobić cokolwiek w F #, ale ja się tym trzymam). Jest wielu innych.

• F # ma lepszą wydajność niż C # w matematyce
• Możesz używać projektów F # w tym samym rozwiązaniu z C # (i wywoływać między nimi)
• F # jest naprawdę dobry w przypadku złożonych zastosowań programowania algorytmicznego, finansowych i naukowych
• F # logicznie jest naprawdę dobry do wykonywania równoległego (łatwiej jest wykonać kod F # na rdzeniach równoległych, niż C #)

Aby odpowiedzieć na twoje pytanie tak, jak je rozumiem: Dlaczego używać C #? (Mówisz, że jesteś już sprzedany na F #.)

Po pierwsze. Nie chodzi tylko o „funkcjonalność kontra OO”. To „Funkcjonalne + OO kontra OO”. Funkcje funkcjonalne języka C # są dość podstawowe. F # nie są. W międzyczasie F # wykonuje prawie wszystkie funkcje OO języka C #. W większości F # kończy się jako nadzbiór funkcji języka C #.

Jest jednak kilka przypadków, w których F # może nie być najlepszym wyborem:

• Interop. Istnieje wiele bibliotek, które po prostu nie będą zbyt wygodne w języku F #. Być może wykorzystują pewne rzeczy C # OO, których F # nie robi tego samego, albo może polegają na wewnętrznych elementach kompilatora C #. Na przykład Expression. Chociaż można łatwo przekształcić cytat F # w wyrażenie, wynik nie zawsze jest dokładnie tym, co utworzyłby C #. Niektóre biblioteki mają z tym problem.

  • Tak, interop to dość duża sieć i może powodować pewne tarcia z niektórymi bibliotekami.

  • Uważam, że interop obejmuje również, jeśli masz dużą istniejącą bazę kodu. Pisanie części w języku F # może nie mieć sensu.

• Narzędzia projektowe. F # nie ma żadnych. Nie oznacza to, że nie może ich mieć, ale teraz nie możesz uruchomić aplikacji WinForms za pomocą kodu F #. Nawet tam, gdzie jest obsługiwana, na przykład na stronach ASPX, obecnie nie jest dostępna technologia IntelliSense. Musisz więc dokładnie rozważyć, jakie będą twoje granice dla wygenerowanego kodu. W przypadku naprawdę małego projektu, w którym prawie wyłącznie korzystają różni projektanci, może nie być warto używać F # do „kleju” lub logiki. W przypadku większych projektów może to stać się mniejszym problemem.

  • To nie jest wewnętrzny problem. W przeciwieństwie do odpowiedzi Rexa M, nie widzę niczego wewnętrznego w C # lub F #, co czyniłoby je lepszymi do tworzenia interfejsu użytkownika z wieloma zmiennymi polami. Może odnosił się do dodatkowego obciążenia związanego z napisaniem „mutable” i użyciem <- zamiast =.

  • Zależy również od używanej biblioteki / projektanta. Uwielbiamy używać ASP.NET MVC z F # dla wszystkich kontrolerów, a następnie projekt sieci Web C #, aby uzyskać projektantów ASPX. W zależności od tego, czego potrzebujemy na tej stronie, mieszamy rzeczywisty „kod wbudowany” ASPX między C # i F #. (IntelliSense a typy F #).

• Inne narzędzia. Mogą po prostu oczekiwać tylko języka C # i nie wiedzieć, jak radzić sobie z projektami F # lub skompilowanym kodem. Ponadto biblioteki F # nie są dostarczane jako część .NET, więc masz trochę więcej do wysłania.

• Ale problem numer jeden? Ludzie. Jeśli żaden z twoich programistów nie chce uczyć się F # lub, co gorsza, nie ma poważnych trudności ze zrozumieniem pewnych aspektów, prawdopodobnie masz toast. (Chociaż w takim przypadku i tak uważam, że jesteś upieczony.) Och, a jeśli kierownictwo powie nie, to może być problem.

Pisałem o tym jakiś czas temu: Dlaczego NIE F #?

Prosisz o porównanie między językiem proceduralnym a językiem funkcjonalnym, więc czuję, że odpowiedź na twoje pytanie można znaleźć tutaj: Jaka jest różnica między programowaniem proceduralnym a programowaniem funkcjonalnym?

Jeśli chodzi o to, dlaczego MS stworzyło F #, odpowiedź jest prosta: stworzenie języka funkcjonalnego z dostępem do biblioteki .Net po prostu rozszerzyło ich bazę rynkową. A widząc, że składnia jest prawie identyczna z OCaml, naprawdę nie wymagało to dużego wysiłku z ich strony.

F # nie jest jeszcze innym językiem programowania, jeśli porównujesz go z C #, C ++, VB. C #, C, VB to imperatywne lub proceduralne języki programowania. F # to funkcjonalny język programowania.

Dwie główne zalety języków programowania funkcyjnego (w porównaniu z językami imperatywnymi) to: 1. brak efektów ubocznych. To znacznie ułatwia matematyczne rozumowanie na temat właściwości twojego programu. 2. że funkcje są obywatelami pierwszej kategorii. Możesz przekazywać funkcje jako parametry do innych funkcji równie łatwo, jak inne wartości.

Zarówno imperatywne, jak i funkcjonalne języki programowania mają swoje zastosowania. Chociaż nie wykonałem jeszcze żadnej poważnej pracy w F #, obecnie wdrażamy komponent planowania w jednym z naszych produktów w oparciu o C # i zamierzamy przeprowadzić eksperyment, kodując ten sam harmonogram w F #, aby sprawdzić, czy poprawność implementację można zweryfikować łatwiej niż w przypadku jej odpowiednika w języku C #.

F # to zasadniczo C ++ języków programowania funkcjonalnego. Zachowali prawie wszystko z Objective Caml, w tym naprawdę głupie części, i wrzucili go do środowiska uruchomieniowego .NET w taki sposób, że zawiera również wszystkie złe rzeczy z .NET.

Na przykład w przypadku Objective Caml otrzymujesz jeden typ wartości null, opcję <T>. Za pomocą F # otrzymujesz trzy typy wartości null, option <T>, Nullable <T> i odwołania do wartości null. Oznacza to, że jeśli masz opcję, musisz najpierw sprawdzić, czy jest to „Brak”, a następnie musisz sprawdzić, czy jest to „Niektóre (null)”.

F # jest jak stary klon Java J #, tylko po to, by przyciągnąć uwagę. Niektórym się spodoba, kilku nawet będzie go używać, ale ostatecznie jest to nadal dwudziestoletni język dołączony do CLR.

Jednym z aspektów .NET, które najbardziej lubię, są generyczne. Nawet jeśli piszesz kod proceduralny w języku F #, nadal będziesz korzystać z wnioskowania o typie. Ułatwia pisanie kodu ogólnego.

W języku C # domyślnie piszesz konkretny kod i musisz włożyć trochę dodatkowej pracy, aby napisać kod ogólny.

W języku F # domyślnie piszesz kod ogólny. Po ponad roku programowania w językach F # i C # stwierdzam, że kod biblioteki, który piszę w języku F #, jest zarówno bardziej zwięzły, jak i bardziej ogólny niż kod, który piszę w C #, a zatem jest również bardziej wielokrotnego użytku. Brakuje mi wielu okazji do pisania kodu ogólnego w C #, prawdopodobnie dlatego, że oślepiają mnie obowiązkowe adnotacje typu.

Są jednak sytuacje, w których preferowane jest używanie języka C #, w zależności od gustu i stylu programowania.

• C # nie narzuca kolejności deklaracji między typami i nie jest wrażliwy na kolejność, w jakiej są kompilowane pliki.
• C # ma pewne niejawne konwersje, na które F # nie może sobie pozwolić z powodu wnioskowania o typie.