Ürün sevkiyatından daha fazla prototipleme yapan bir teknoloji şirketi için çalışıyorum. Sadece C # ve F # arasındaki farkın ne olduğu, MS neden F # oluşturduğu ve hangi senaryoların C # 'dan daha iyi olacağı soruldu.
Dili bir süredir kullanıyorum ve F # 'ın harika özellikleri hakkında kolayca devam edebilmek için seviyorum, ancak C # konusunda neden birini diğerine kullanmamız gerektiğini söyleyecek deneyimim yok.
C # - F # veya F # - C # kullanmanın faydaları nelerdir?
Yanıtlar:
İşlevsel programlamanın zorunlu dillere göre genel faydaları:
F # gibi işlevsel bir programlama dilinde birçok sorunu çok daha kolay, tanımlarına daha yakın ve daha özlü bir şekilde formüle edebilirsiniz ve kodunuz daha az hataya meyillidir (değişmezlik, daha güçlü tip sistemi, sezgisel yeniden yapılandırma algoritmaları). Bilgisayarın söylemenizi istediği şey yerine ne demek istediğinizi kodlayabilirsiniz ;-) Google'da Google'da aradığınızda veya hatta SO'da aradığınızda bunun gibi birçok tartışma bulacaksınız.
Özel F # - avantajları:
Asenkron programlama olduğu son derece kolay ve sezgisel async {}-expressions - Hatta ParallelFX ile ilgili C # -Kod çok daha büyük
Derleyici derleyicilerinin ve etki alanına özel dillerin çok kolay entegrasyonu
Dili ihtiyaç duyduğunuz kadar genişletme: LOP
Daha esnek sözdizimi
Genellikle daha kısa ve daha zarif çözümler
Bu belgeye bir göz atın
C # 'ın avantajları, "zorunlu" uygulamalara (Kullanıcı arabirimi, zorunlu algoritmalar) işlevsel bir programlama dilinden daha doğru olması, kullandığı .NET-Framework'ün zorunlu olarak tasarlanması ve daha yaygın olmasıdır.
Ayrıca F # ve C # 'yi tek bir çözümde bir arada bulundurabilirsiniz, böylece her iki dilin avantajlarını birleştirebilir ve ihtiyaç duyuldukları yerde kullanabilirsiniz.
Çekiçin tornavidaya göre faydasının ne olduğunu sormak gibi. Son derece yüksek bir seviyede, ikisi de esasen aynı şeyi yapar, ancak uygulama düzeyinde, başarmaya çalıştığınız şey için en uygun aracı seçmek önemlidir. C # 'da zor ve zaman alıcı, ancak f #' de kolay olan - bir tornavidayla bir çivi çakmaya çalışmak gibi görevler vardır. Kesinlikle yapabilirsiniz - bu ideal değil.
Veri manipülasyonu, kişisel olarak f #'ın gerçekten parladığı ve c # 'nin potansiyel olarak kullanışsız olabileceğini gösterebileceğim bir örnektir. Kapak tarafında, (genel olarak konuşursak) karmaşık durum bilgisi olan kullanıcı arayüzünün OO (c #) 'da işlevselden (f #) daha kolay olduğunu söyleyebilirim. ( F # dilinde herhangi bir şeyi yapmanın ne kadar kolay olduğunu "kanıtlamak" şu anda "havalı" olduğu için muhtemelen buna katılmayan bazı insanlar olacaktır , ama ben onun yanında duruyorum). Sayısız başkaları var.
inlineF # 'da C #' nin ifade edemeyeceği büyük performans iyileştirmeleri sağlayabilecek bir şeyin açık bir örneğidir.
Sorunuzu anladığım şekilde cevaplamak için: Neden C # kullanıyorsunuz? (Zaten F # üzerinde satıldığını söylüyorsun.)
İlki. Bu sadece "OO'ya karşı işlevsel" değil. "Fonksiyonel + OO'ya karşı OO". C # 'ın işlevsel özellikleri oldukça ilkeldir. F # 'ler değildir. Bu arada, F #, C # 'ın neredeyse tüm OO özelliklerini gerçekleştirir. Çoğunlukla, F #, C # işlevinin bir üst kümesi olarak sona erer.
Bununla birlikte, F # 'nın en iyi seçenek olmayabileceği birkaç durum vardır:
Birlikte çalışma. F # 'dan çok rahat olmayacak birçok kütüphane var. Belki de F #'ın aynı şeyi yapmadığı belirli C # OO şeylerinden yararlanırlar veya belki de C # derleyicisinin iç bileşenlerine güvenirler. Örneğin, İfade. Bir F # teklifini bir İfadeye kolayca dönüştürebilirsiniz, ancak sonuç her zaman tam olarak C # 'nın yaratacağı şey değildir. Bazı kütüphanelerin bununla bir sorunu var.
Evet, birlikte çalışma oldukça büyük bir ağdır ve bazı kitaplıklarla biraz sürtüşmeye neden olabilir.
Büyük bir kod tabanınız varsa, birlikte çalışmayı da dahil etmeyi düşünüyorum. Parçaları F # ile yazmaya başlamak mantıklı olmayabilir.
Tasarım araçları. F # 'de hiç yok. Bu hiçbirine sahip olamayacağı anlamına gelmez , ancak şu anda bir WinForms uygulamasını F # codebehind ile hazırlayamazsınız. Desteklendiği yerlerde bile, ASPX sayfalarında olduğu gibi, şu anda IntelliSense almazsınız. Bu nedenle, oluşturulan kod için sınırlarınızın nerede olacağını dikkatlice düşünmeniz gerekir. Neredeyse sadece çeşitli tasarımcıları kullanan gerçekten küçük bir projede, "yapıştırıcı" veya mantık için F # kullanmaya değmeyebilir. Daha büyük projelerde bu daha az sorun haline gelebilir.
Bu içsel bir sorun değil. Rex M'nin cevabının aksine, C # veya F # ile ilgili çok sayıda değiştirilebilir alan içeren bir kullanıcı arayüzü yapmalarını daha iyi hale getiren içsel hiçbir şey görmüyorum. Belki de "değişken" yazmak zorunda kalmanın ve = yerine <- kullanmanın fazladan yükünden bahsediyordu.
Ayrıca kullanılan kitaplığa / tasarımcıya da bağlıdır. Tüm denetleyiciler için F # ile ASP.NET MVC'yi, ardından ASPX tasarımcılarını almak için bir C # web projesi kullanmayı seviyoruz. O sayfada neye ihtiyacımız olduğuna bağlı olarak, gerçek ASPX "kod satır içi" ni C # ve F # arasında karıştırıyoruz. (IntelliSense ve F # türleri.)
Diğer Aletler. Yalnızca C # bekliyor olabilirler ve F # projeleri veya derlenmiş kodlarla nasıl başa çıkacaklarını bilmiyor olabilirler. Ayrıca, F # kütüphaneleri .NET'in bir parçası olarak gönderilmez, bu yüzden biraz daha fazla yollayabilirsiniz.
Ama bir numaralı mesele? İnsanlar. Geliştiricilerinizden hiçbiri F # öğrenmek istemiyorsa veya daha kötüsü, belirli yönleri anlamakta ciddi zorluk çekmiyorsa, muhtemelen kızardınız. (Yine de, bu durumda yine de kızardığınızı iddia ediyorum.) Oh, ve eğer yönetim hayır derse, bu bir sorun olabilir.
Bunun hakkında bir süre önce yazdım: Neden F # DEĞİL?
Prosedürel bir dil ile işlevsel bir dil arasında bir karşılaştırma yapmak istiyorsunuz, bu yüzden sorunuzun burada cevaplanabileceğini düşünüyorum: Prosedürel programlama ile fonksiyonel programlama arasındaki fark nedir?
MS'in neden F #'ı oluşturduğuna gelince, cevap basittir: .Net kitaplığına erişime sahip işlevsel bir dil oluşturmak, pazar tabanını genişletti. Ve sözdiziminin OCaml ile neredeyse aynı olduğunu görünce, onlar açısından çok fazla çaba gerektirmedi.
C #, C ++, VB ile karşılaştırıyorsanız, F # henüz başka bir programlama dili değildir. C #, C, VB'nin tümü zorunlu veya prosedürel programlama dilleridir. F #, işlevsel bir programlama dilidir.
İşlevsel programlama dillerinin (zorunlu dillere kıyasla) iki ana faydası, 1. yan etkilerinin olmamasıdır. Bu, programınızın özellikleri hakkında matematiksel akıl yürütmeyi çok daha kolaylaştırır. 2. bu işlevler birinci sınıf vatandaşlardır. İşlevleri, diğer değerlerde olduğu gibi başka işlevlere de kolayca geçirebilirsiniz.
Hem zorunlu hem de işlevsel programlama dillerinin kullanımları vardır. Henüz F # konusunda ciddi bir çalışma yapmamış olsam da, şu anda ürünlerimizden birinde C # tabanlı bir zamanlama bileşeni uyguluyoruz ve aynı zamanlayıcıyı F # 'da kodlayarak bir deney yapacağız. uygulama C # eşdeğeriyle olduğundan daha kolay doğrulanabilir.
F #, esasen işlevsel programlama dillerinin C ++ 'dır. Gerçekten aptal parçalar da dahil olmak üzere hemen hemen her şeyi Objective Caml'den sakladılar ve .NET'in tüm kötü şeylerini de getirecek şekilde .NET çalışma zamanının üstüne attılar.
Örneğin, Objective Caml ile bir tür null, <T> seçeneği elde edersiniz. F # ile üç tür null, seçenek <T>, Nullable <T> ve referans null değerleri elde edersiniz. Bu, bir seçeneğiniz varsa, önce "Hiçbiri" olup olmadığını kontrol etmeniz, ardından "Bazı (boş)" olup olmadığını kontrol etmeniz gerektiği anlamına gelir.
F #, eski Java klonu J # gibidir, sadece dikkat çekmek için piçleştirilmiş bir dildir. Bazı insanlar onu sevecek, hatta birkaçı onu kullanacak, ancak sonunda CLR'ye bağlı 20 yıllık bir dil.
Some nullherhangi bir F # kodundaki kodu hiç görmedim . İnsanların şikayet edebileceği her şey arasında, bu listede beklemek zorunda ...
.NET'in en sevdiğim yönlerinden biri de jenerikler. F # ile yordamsal kod yazsanız bile, yine de tür çıkarımından yararlanacaksınız. Genel kod yazmayı kolaylaştırır.
C # 'da varsayılan olarak somut kod yazarsınız ve genel kod yazmak için fazladan iş yapmanız gerekir.
F # 'da, varsayılan olarak genel kod yazarsınız. Hem F # hem de C # için bir yıldan fazla programlama harcadıktan sonra, F # ile yazdığım kütüphane kodunun C # ile yazdığım koddan hem daha kısa hem de daha genel olduğunu ve bu nedenle de daha yeniden kullanılabilir olduğunu gördüm. Muhtemelen zorunlu tür ek açıklamaları beni kör ettiğinden, C # ile genel kod yazmak için birçok fırsatı kaçırıyorum.
Ancak, kişinin zevkine ve programlama stiline bağlı olarak C # kullanmanın tercih edildiği durumlar vardır.