"एफ # एंटिटी फ्रेमवर्क या डब्ल्यूपीएफ से अधिक कठिन नहीं है": स्कॉट व्लाशिन के साथ साक्षात्कार

मुझे F # के बारे में किससे पूछना चाहिए, अगर ऐसा व्यक्ति नहीं जिसने इस भाषा के लिए एक विस्तृत वेबसाइट समर्पित की हो? स्कॉट व्लाशिन ने कई हाबरा निवासियों के लिए परिचित "फ # फॉर फन एंड प्रॉफिट" संसाधन तैयार किया: वहां से हैबर ने लेखों की एक श्रृंखला "कार्यात्मक सोच" और एक लेख "रेलवे-ओरिएंटेड प्रोग्रामिंग" दोनों का अनुवाद किया।

और नवंबर में, वह "रचना की शक्ति" रिपोर्ट के साथ मास्को में हमारे डॉटनेक्स्ट सम्मेलन में बात करेंगे। और इस भाषण की प्रत्याशा में, हमने उनसे F # और आमतौर पर कार्यात्मक प्रोग्रामिंग के बारे में पूछा।

- चलो शुरू से ही चलते हैं: कार्यात्मक प्रोग्रामिंग से पहले आपने क्या किया, आप एफ # कैसे आए और आपने साइट कैसे बनाई?

- मैं आदरणीय उम्र का आदमी हूं, और जब मैं विश्वविद्यालय में था, तब तक कोई अलग कंप्यूटर विज्ञान कार्यक्रम नहीं थे। मैंने एक गणितीय शिक्षा प्राप्त की, लेकिन गणित नहीं करना चाहता था, इसलिए विश्वविद्यालय के बाद मैंने कारपेंटर सहित विभिन्न नौकरियों पर लगभग 10 वर्षों तक काम किया।

1980 के दशक के उत्तरार्ध में एक अच्छा दिन, मेरे पिता ने एक कंप्यूटर, CP / M Kaypro खरीदा, जिसमें थोड़ी मात्रा में स्मृति और 5.25 इंच के फ्लॉपी डिस्क थे। यह विंडोज के प्रदर्शित होने से पहले था, इसलिए डॉस इस पर खड़ा था। यह उस पर था कि मैंने प्रोग्रामिंग शुरू की। मैं डेटाबेस में लगा हुआ था, सबसे पहले मेरे पिता के लिए, उन्हें अपने काम के लिए इसकी आवश्यकता थी। और फिर मैंने इसे पेशेवर रूप से करना शुरू कर दिया।

मेरी पहली भाषा टर्बो पास्कल थी, और 1989 या 1990 में मैं स्मॉलटाक से मिला, और मुझे यह वास्तव में पसंद आया, यह अभी भी मेरी पसंदीदा भाषाओं में से एक है। एक नौकरी ने दूसरी जगह ले ली, और अंत में, अधिकांश प्रोग्रामर की तरह, मुझे बोरिंग व्यावसायिक अनुप्रयोगों को लिखने के लिए एक बड़ी कंपनी में नौकरी मिली (मैं उन्हें "BLOBs" कहता हूं: बोरिंग लाइन-ऑफ-बिजनेस एप्लिकेशन)। और बहुत लंबे समय से वह बस यही कर रहा था।

थोड़ी देर के लिए मैंने पायथन में लिखा, लगभग 10 साल - सी # में। और 2011 में, यानी इतने समय पहले नहीं, मैंने फैसला किया कि मैं अपने काम से थक गया हूं और कुछ नया करने की कोशिश करना अच्छा होगा; इसलिए मैं कार्यात्मक प्रोग्रामिंग करना चाहता था। यह पता चला कि मेरे विज़ुअल स्टूडियो में पहले से ही एक कार्यात्मक भाषा थी, इसलिए मैंने एफ # को समझने की कोशिश की। और पहली बार में यह बहुत अजीब लग रहा था, मैं कुछ भी नहीं समझ सकता था, यह उस सब से अलग था जो मैंने पहले काम किया था।

एफ # पर कई अच्छे ब्लॉग थे, लेकिन उनमें से बहुत कम थे, और पर्याप्त दस्तावेज भी नहीं थे। नतीजतन, मेरे दोस्तों ने मुझे उत्कृष्ट सलाह दी: यदि आप किसी चीज का ठीक से अध्ययन करना चाहते हैं, तो दूसरों को इसके बारे में पढ़ाना शुरू करने की कोशिश करें, क्योंकि यह आपको विषय को अच्छी तरह से समझने में सक्षम बनाता है। इसके अलावा, मुझे एक ब्लॉग शुरू करने की सलाह दी गई थी, इससे मुझे अन्य प्रोग्रामरों के बीच खड़ा होने की अनुमति मिली।

सामान्य तौर पर, 2012 में मैंने ब्लॉग "एफ # फॉर फन एंड प्रॉफिट" शुरू किया और हर बार जब मैंने एफ # से कुछ नया सीखा, उसमें लेख प्रकाशित करना शुरू किया। अब कई सौ पृष्ठ हैं, और इसने बहुत लोकप्रियता हासिल की है। पहले यह सिर्फ एक शौक था, मैंने अपने खाली समय में इस पर काम किया। और लगभग 3 या 4 साल पहले, मैंने अपनी नौकरी छोड़ दी और फ्रीलांस सलाहकार बन गया। पिछले साल से पहले, मैंने एक किताब लिखी थी, जो काफी लोकप्रिय हुई। और इसलिए F # से मेरा परिचय हुआ।

- आप एफ # के साथ एक फ्रीलांसर के रूप में कैसे काम करते हैं, या न केवल?

- मूल रूप से, एफ #, हालांकि आम तौर पर बोलते हुए, वे क्या भुगतान करेंगे - यही कारण है कि मैं * हंसी * की सलाह देता हूं। अगर मुझे पैसे की ज़रूरत है, लेकिन किसी के पास C # पर काम है, और यह दिलचस्प लग रहा है, तो मैं इसे लेता हूं। और पिछले साल, मैंने पायथन के साथ तीन महीने तक काम किया। मेरे लिए जो मायने रखता है वह भाषा नहीं है, लेकिन किस विशेष समस्या को हल करना है। मुझे अध्ययन करना पसंद है, और जब आपको किसी समस्या को हल करने के लिए काम पर रखा जाता है, तो आपको बनना पड़ता है, यदि कोई विशेषज्ञ नहीं है, तो कम से कम एक नए क्षेत्र को हल करें।

इस तरह मुझे रियल एस्टेट अर्थशास्त्र और बीमा जोखिमों का अध्ययन करना पड़ा। मेरा मानना ​​है कि अच्छा कोड केवल तभी लिखा जा सकता है जब आपके पास उस विषय की अच्छी समझ हो जो आप कर रहे हैं और केवल वही नहीं लिखें जो दूसरे आपको बताते हैं। मेरे लिए, यह सबसे दिलचस्प है - एक भाषा नहीं, बल्कि एक समस्या है।

- रूस में, हालांकि कुछ डेवलपर्स को F # में रुचि है, इस भाषा के साथ व्यापार करना मुश्किल है: C # की तुलना में डेवलपर को खोजना या बदलना अधिक कठिन है। और जिन कंपनियों के साथ आप काम करते हैं, वे एफ # में कैसे हल होते हैं?

- दो सबसे आम स्थितियां हैं। पहला विकल्प तब होता है जब कंपनी पहले से ही F # का उपयोग करती है, उनके पास आमतौर पर किसी प्रकार का पायलट प्रोजेक्ट होता है। वे मुझे फोन करते हैं और मुझे इस प्रोजेक्ट को लॉन्च करने और उन्हें भाषा सिखाने में मदद करने के लिए कहते हैं। आमतौर पर वे इस तरह की परियोजना पर लगभग छह महीने बिताने के लिए तैयार होते हैं ताकि यह पता लगाया जा सके कि वे आगे ऐसा करना चाहते हैं या नहीं।

इसके अलावा, मैं लोगों को डोमेन-संचालित डिज़ाइन सिखाने में लगा हूं, और यहाँ F # स्पॉटलाइट में नहीं है, लेकिन मैं इसे एक भाषा के रूप में उपयोग करता हूं। मैं प्रोग्रामरों को C # का आदी दिखा रहा हूं कि F # में समान कोड C # की तुलना में कितना कम हो सकता है। यानी मैं चुपचाप भाषा को बढ़ावा देता हूं। यह मदद करता है कि आपको F # पर पूरी तरह से स्विच करने की ज़रूरत नहीं है, आप F # में एक डोमेन मॉडल लिख सकते हैं, और C # में सब कुछ।

- आप कहते हैं कि C # और F # का एक साथ उपयोग किया जा सकता है। लेकिन C # में, Entity Framework, NHibernate, या कुछ इसी तरह का सबसे अधिक उपयोग किया जाता है। और F # पर डेवलपर्स के बीच यह बहुत कम लोकप्रिय है। दृष्टिकोण में अंतर को ध्यान में रखते हुए इन भाषाओं को कैसे मिलाएं?

- जिन कंपनियों के साथ मैंने काम किया उनमें से एक ने Entity Framework का उपयोग किया है। उन्होंने पोर्ट्स और एडेप्टर्स आर्किटेक्चर पर स्विच करने की कोशिश की, यानी आर्किटेक्चर के मूल से सभी इनपुट / आउटपुट ऑपरेशन को हटा दिया। इसके लिए, Entity Framework बहुत बुरा है। ऐसी स्थितियों में, डैपर जैसी किसी चीज़ का उपयोग करना अधिक सुविधाजनक होता है, जो आपको अपने कोड के बीच में एसक्यूएल से निपटने की अनुमति नहीं देता है। अन्य बातों के अलावा, यह परीक्षण को आसान बनाता है।

उन्हें कार्यात्मक प्रोग्रामिंग का उपयोग न करने दें, लेकिन स्थिति अभी भी उन्हें कार्यक्रम का एक स्वच्छ कोर होने के लिए धक्का देती है, और डेटाबेस को कहीं न कहीं परिधि पर रखती है। अगर सोच इस प्रारूप में बदल गई है, तो यह एंटिटी को छोड़ने की दिशा में एक महत्वपूर्ण कदम है। ऐसी कंपनी में, मैं, वास्तव में, कुछ भी नहीं बदला होगा। आप लोगों को बदलने के लिए मजबूर नहीं कर सकते हैं, वे खुद बदलाव चाहते हैं। मैं अपने आप को बेचने की कोशिश नहीं कर रहा हूं और किसी को उस तरह से लागू करना चाहता हूं जो मुझे लगता है कि सबसे अच्छा है। आमतौर पर लोग पहले से ही बदलना चाहते हैं, और मैं उन्हें इसे हासिल करने में मदद करता हूं। क्या आप समझते हैं कि मेरा क्या मतलब है?

- अर्थात्, आपके ग्राहक ऐसी कंपनियां हैं जो स्वयं पहले से ही अधिक कार्यात्मक दृष्टिकोण के लिए आगे बढ़ रही हैं।

- भले ही वे C # के साथ काम करते हों, लेकिन वे अधिक कार्यात्मक C # पर स्विच करते हैं, LINQ का उपयोग करना शुरू करते हैं, अपरिवर्तनीय डेटा संरचनाएं, अर्थात, सामान्य रूप से, इस दिशा में जाते हैं। इसलिए, उनके लिए, एफ # पर स्विच करना अब एक बड़ी छलांग नहीं है।

एक डेवलपर और एक बढ़ई के समान हैं

- आपके पास एक प्रोग्रामर और एक बढ़ई के काम की तुलना करने वाले ट्विटर पर एक दिलचस्प धागा है। मैं "कार्यात्मकता" के बारे में पूछना चाहूंगा, जो इस धागे से शुरू होगा। लेकिन क्या आप हमारे पाठकों के लिए इसका सार बता सकते हैं?

- डेवलपर्स खुद की तुलना इंजीनियरों और सॉफ्टवेयर डेवलपमेंट से करना पसंद करते हैं - इमारतों या पुलों के निर्माण के साथ। और इस बारे में बहुत बहस है कि क्या प्रोग्रामिंग वास्तव में इन गतिविधियों के करीब है, या क्या वे मौलिक रूप से अलग हैं। जैसे, हमारे पास हर दिन बदलने वाली परियोजना के लिए आवश्यकताएं हैं - जब आप एक पुल का निर्माण करते हैं, तो शायद सब कुछ पूरी तरह से गलत है? या वास्तव में ऐसा है भी?

लेकिन मेरा मानना ​​है कि इस विवाद में एक भी सही जवाब नहीं है। मैं कभी इंजीनियर नहीं रहा, लेकिन मैं एक बढ़ई था। और मैं कह सकता हूं कि बढ़ई के पास बहुत सारे काम हैं, प्रारूप में बहुत अलग हैं, और प्रत्येक को अपने दृष्टिकोण की आवश्यकता है।

उदाहरण के लिए, एक काम में मैंने रसोई अलमारियाँ की। अमेरिका में, वे सभी बहुत मानकीकृत हैं, सभी समान आकार, एक दूसरे के अनुरूप हैं, और बिजली उपकरणों के साथ काम किया जा रहा है। यह कुछ गुणवत्ता प्रदान करने के लिए आवश्यक है, लेकिन अमेरिका में, पुराने रसोईघर को आमतौर पर फेंक दिया जाता है जब घर अपने मालिक को बदलता है, अर्थात यह बहुत लंबे समय तक सेवा नहीं करेगा। तो इस काम में, सब कुछ गति और लागत बचत से बंधा है।

फिर मेरा एक और काम था, जहाँ मुझे बिल्डिंग के कमरे के बीच में एक बड़े, 6 इंच के ओक बीम को बदलने की जरूरत थी, जो 400-500 साल पुराना था। यहां सब कुछ विपरीत था: सब कुछ घुमावदार था, कोई समकोण नहीं था, और इसे बदलने के लिए, लकड़ी के एक नए टुकड़े को मैन्युअल रूप से फिट करना आवश्यक था, ताकि पुराने के समान आकार हो। इसके लिए बहुत सटीकता की आवश्यकता थी।

अंत में, तीसरा काम था जिसमें मैंने मंच के लिए दृश्यावली की। वे प्रॉप्स के लिए प्लाईवुड और बहुत पतली लकड़ी से बने थे।

मेरा विचार है कि प्रत्येक कार्य के लिए अपने दृष्टिकोण की आवश्यकता होती है। रसोई अलमारियाँ के मामले में, सटीक, बिजली उपकरणों के उपयोग और प्रतिलिपि प्रस्तुत करने योग्य परिणामों की आवश्यकता होती है। एक पुराने लकड़ी के घर में आप एक विरासत प्रणाली के साथ काम करते हैं, सावधान रहना महत्वपूर्ण है, जल्दी करने के लिए नहीं, आपको गति की आवश्यकता नहीं है, लेकिन परिणाम की शुद्धता। अंत में, सजावट के मामले में, आप जानबूझकर एक नाजुक संरचना बनाते हैं जिसमें मजबूत नहीं होना पड़ता है, आपको अक्सर इसे काटना पड़ता है और इसे कुछ मिनटों में फिर से इकट्ठा करना पड़ता है, ऐसी संरचनाएं हमेशा के लिए नहीं रहती हैं।

जब वे कहते हैं कि प्रोग्रामिंग इंजीनियरिंग के समान है, तो यह केवल कुछ प्रकार की प्रोग्रामिंग के लिए सही है। उदाहरण के लिए, यदि आप एक हवाई जहाज को नियंत्रित करने वाले सॉफ़्टवेयर लिखते हैं, तो आपको बहुत सावधान रहने और बहुत अधिक सटीकता प्राप्त करने की आवश्यकता है। फ़ाइलों के लिए खोज करने के लिए एक पूरी तरह से अलग चीज एक-लाइन स्क्रिप्ट है, यह दृश्यों को बनाने की तरह है। यह साबित करने में 20 घंटे खर्च करने का कोई मतलब नहीं है कि यह स्क्रिप्ट काम करती है और इसके लिए 1000 यूनिट परीक्षण लिख रहा है। सभी काम 5 मिनट से अधिक नहीं होने चाहिए। और जब आप एक विरासत प्रणाली के साथ काम करते हैं, तो आपको अपने कोड को मौजूदा एक के रूप में संभव के रूप में फिट करने की आवश्यकता होती है, बड़ी रीफैक्टरिंग यहां अवांछनीय है।

यही है, प्रत्येक मामले में, संदर्भ महत्वपूर्ण है। कभी-कभी आपको बहुत योजना बनाने की ज़रूरत होती है, किसी परियोजना के बारे में बहुत कुछ सोचते हैं, बहुत सारे परीक्षण लिखते हैं। अन्य मामलों में, यह कुछ कोड़ा मारने के लिए पर्याप्त है। बहुत से लोगों को इस संबंध में लचीलेपन की कमी है, उनका मानना ​​है कि यदि आप इकाई परीक्षणों का उपयोग नहीं करते हैं या कुछ प्रोग्रामिंग भाषा का उपयोग नहीं करते हैं, तो आप एक पेशेवर नहीं हैं। वास्तव में, यह विचार कि यह सब संदर्भ पर निर्भर करता है, बहुत स्पष्ट है। हैरानी की बात यह है कि कुछ प्रोग्रामर कैसे अपने विचारों पर जोर देते हैं, और यदि आप कम से कम किसी तरह उनके आदर्शों से विचलित होते हैं, तो आपको तुरंत ब्लैक लिस्ट में भेज दिया जाता है। मेरी राय में, यह बेवकूफी है।

- आप कहते हैं कि बाहरी पर्यवेक्षक के लिए गतिविधि एक समान दिखती है, लेकिन जब आप इसे अंदर से देखते हैं, तो पूरी तरह से अलग मामले सामने आते हैं। और मैं पूछना चाहता हूं: क्या यह कार्यात्मक प्रोग्रामिंग के साथ समान है? जो लोग बाहर से देखते हैं उनमें एक सामान्य रूढ़ि है, लेकिन वास्तव में विशाल अंतर हैं?

- ठीक है। बाहर से ऐसा लग सकता है कि सभी "पदाधिकारी" समान रूप से सोचते हैं, लेकिन कई अलग-अलग समूह हैं जो एक-दूसरे के साथ बहस करते हैं: हास्केल, एफ #, क्लोजर, एल्म के समर्थक। एफ # के अंदर भी, इस बात पर जोरदार असहमति है कि यह भाषा किस दिशा में विकसित होनी चाहिए - क्या आपको हास्केल की नकल करने की कोशिश करनी चाहिए या उपयोग में आसानी को प्राथमिकता देना चाहिए। तो आप सही हैं, इस क्षेत्र के अंदर बाहरी पर्यवेक्षकों की तुलना में बहुत अधिक विविध हैं जो आमतौर पर इसकी कल्पना करते हैं।

- बढ़ई के काम में अंतर के लिए, आपने बहुत स्पष्ट उदाहरण दिए। क्या आप विशिष्ट उदाहरणों के साथ कार्यात्मक प्रोग्रामिंग में अंतर का वर्णन कर सकते हैं?

- कार्यात्मक प्रोग्रामिंग का एक स्कूल है, जो मानता है कि आपको सब कुछ साबित करने की कोशिश करने की आवश्यकता है, और ताकि सब कुछ गणितीय रूप से परिपूर्ण हो। यह स्कूल बहुत सारे गणितीय शब्दजाल का उपयोग करता है, उदाहरण के लिए, "मोनॉयड्स" या "मोनडेस।" ये मुख्य रूप से हास्केल उपयोगकर्ता हैं, और शैक्षणिक वातावरण बहुत प्रभावशाली है।

और ऐसे लोग हैं जो परिणाम प्राप्त करने के लिए अधिक महत्वपूर्ण हैं। वे गणित में इतनी दिलचस्पी नहीं रखते हैं जितनी कि अपरिवर्तनीयता और मैं / ओ परिधि को हटाने में। इस दृष्टिकोण का सबसे अच्छा उदाहरण एल्म समुदाय है। वे मुख्य रूप से वेब अनुप्रयोगों के निर्माण में शामिल हैं। पहले समूह के विपरीत, यहां वे सचेत रूप से गणितीय शब्दजाल का उपयोग नहीं करते हैं, और वे जानबूझकर उस कार्यक्षमता के भाग को अस्वीकार कर देते हैं जो हास्केल में है और जिसे हास्केल उपयोगकर्ता महत्वपूर्ण मानते हैं।

इसके अलावा, मजबूत टाइपिंग और गतिशील टाइपिंग के समर्थकों के बीच विवाद है। आम आदमी की दृष्टि में, कार्यात्मक प्रोग्रामिंग कुछ हास्केल या एफ # की तरह है, लेकिन उनके अलावा, क्लॉजुर जैसी भाषाएं हैं जिनमें गतिशील टाइपिंग और समस्याओं को हल करने के लिए एक पूरी तरह से अलग दृष्टिकोण है। यदि आप एक कमरे में इस सभी मोटली कंपनी को इकट्ठा करते हैं, तो वे लड़ सकते हैं। मुझे लगता है कि सभी दृष्टिकोणों का अपना कारण है, और जब मैं किसी के लिए काम करता हूं, तो मैं उन्हें नहीं बताता कि उनका दृष्टिकोण गलत है।

- कई "अकादमिक प्रकृति" ("एफ # एमएल में निहित है, जो कठोर वैज्ञानिक साक्ष्य के लिए है, लेकिन मैं यहां वास्तविक समस्याओं को हल करता हूं") से डरते हैं। लेकिन यह पता चला है कि लोग व्यर्थ में डरते हैं?

- सामान्य तौर पर, यह मुझे अजीब लगता है कि इतने सारे लोग अकादमिकता को कुछ नकारात्मक मानने के आदी हैं। खैर, यह है कि कैसे, कुछ इसे नकारात्मक मानते हैं, अन्य - सकारात्मक।

तथ्य यह है कि अब हम प्रोग्रामिंग में उपयोग की जाने वाली कई प्रौद्योगिकियां शैक्षणिक वातावरण में उत्पन्न हुई हैं, उदाहरण के लिए, कचरा संग्रह या प्रकार। इसलिए स्वयं शैक्षणिक तरीकों में कुछ भी गलत नहीं है। एक और सवाल यह है कि उन पर अत्यधिक जोर देना हानिकारक हो सकता है, क्योंकि वैज्ञानिकों और प्रोग्रामर के अलग-अलग लक्ष्य हैं।

हालाँकि कार्यात्मक भाषाओं की अकादमिक जड़ें हैं, लेकिन यह मुझे F # और एल्म जैसी भाषाओं में इस तर्क को छिपाने का सही सचेत निर्णय लगता है। इसलिए, एफ # का उपयोग प्रमेयों को साबित करने के लिए नहीं किया जाता है, बल्कि वास्तविक समस्याओं को हल करने के लिए, यह एक बहुत ही व्यावहारिक भाषा है। और विश्वविद्यालयों ने अब और भी जटिल भाषाओं, जैसे Coq, F * और इसी तरह स्विच किया है। वे बहुत अधिक अकादमिक हैं, और प्रमेयों को साबित करने के लिए उपयोग किया जाता है।

जैसा कि मैंने कहा, वैज्ञानिक और प्रोग्रामर अलग-अलग चीजें करते हैं। प्रोग्रामर अपना ज्यादातर समय फाइलों को पढ़ने और लिखने, डेटाबेस के साथ काम करने, स्क्रीन पर डेटा प्रदर्शित करने, डेटा दर्ज करने, उन्हें परिवर्तित करने आदि में बिताते हैं, लेकिन वैज्ञानिकों को ऐसी चीजों में कोई दिलचस्पी नहीं है। लेकिन तथ्य यह है कि 40 साल पहले विशुद्ध रूप से अकादमिक चीजें ऐसी थीं जो आज नहीं हैं।

- जैसा कि आपने खुद कहा कि बढ़ई के काम के सिलसिले में, अलग-अलग संदर्भों में अलग-अलग दृष्टिकोण अच्छे हैं, कोई सार्वभौमिक दृष्टिकोण नहीं हैं। और विशेष रूप से, F # भी कुछ कार्यों के लिए सबसे उपयुक्त है। ये कार्य क्या हैं?

- हाँ, यह निश्चित रूप से एक सार्वभौमिक भाषा नहीं है, मैं निश्चित रूप से सभी के लिए इसका उपयोग करने की सिफारिश नहीं करूंगा, यह बेवकूफी होगी। लेकिन यह मुझे लगता है कि एफ # सी # के लिए एक उत्कृष्ट प्रतिस्थापन है - बहुत उच्च प्रदर्शन की आवश्यकता वाले कार्यों के अपवाद के साथ। एफ # में प्रोग्रामिंग पूरी तरह से अलग दृष्टिकोण पर आधारित है: प्रतिरक्षा, संरचनात्मक समानता, स्पष्ट निर्भरता, एफ # में शून्य मान नहीं है, और इसी तरह। और यह मुझे लगता है कि यह दृष्टिकोण रोजमर्रा की प्रोग्रामिंग समस्याओं को हल करने में बहुत अधिक उपयोगी है।

इसलिए, यदि कोई व्यक्ति C # का उपयोग करता है, तो उसे निश्चित रूप से F # के बारे में पूछना चाहिए, यह भाषा कोड को बेहतर बनाने में मदद करेगी। आवेदन के अन्य क्षेत्रों के लिए, यह मुझे लगता है कि एफ # कई कार्यों के लिए अच्छी तरह से अनुकूल होगा जिसके लिए अब पायथन का उपयोग किया जाता है। एफ # और पायथन बहुत समान हैं, और यह मुझे लगता है कि एफ # में डेटा प्रोसेसिंग के लिए बहुत संभावनाएं हैं। फिलहाल, इस क्षेत्र में अभी और काम होना बाकी है, लेकिन शायद कुछ वर्षों में लोग एफ # का उपयोग बड़े डेटा और डेटा साइंस से जुड़ी विभिन्न चीजों के लिए करेंगे, जिसके लिए अब पायथन का उपयोग किया जाता है।

अंत में, एफ # जावास्क्रिप्ट के साथ काम करने के लिए बहुत सुविधाजनक है। सामान्य तौर पर, कोई भी सीधे जावास्क्रिप्ट के साथ काम नहीं करना चाहता है, इसलिए जेएस में संकलन करने वाली कई भाषाएं हैं: उदाहरण के लिए, ReasonML (जो OCaml पर चलती है) और Fable (जो F # पर चलता है)। निजी तौर पर, मैं जावास्क्रिप्ट से निपटने के लिए इनमें से किसी भी विकल्प के साथ काम करना पसंद करता हूं, इसलिए जब दृश्यपटल पर काम करना हो, तो मैं पसंद करने योग्य कुछ चुनूंगा। तो ये तीन मुख्य क्षेत्र हैं जिनमें F # अपना सर्वश्रेष्ठ पक्ष दिखाता है।

- जैसा कि आपने अपनी रिपोर्ट "सी # डेवलपर्स के लिए एफ" में उल्लेख किया है, भाषा में मुख्य बात वाक्यविन्यास नहीं है, लेकिन दर्शन है। लेकिन यहां उन लोगों के लिए कठिनाई है जो जल्दी से समझना चाहते हैं "क्या यह भाषा मुझे सूट करती है।" आप पहले से ही समझ सकते हैं कि क्या आपको एक त्वरित परिचय द्वारा वाक्यविन्यास पसंद है। लेकिन भाषा के दर्शन को समझने में कितना समय लगता है?

- C # लिखने वाला व्यक्ति जल्दी से जावा या गो जैसी भाषा का पता लगा सकता है, क्योंकि इनमें से अधिकांश मानक भाषाओं में लगभग एक अनिवार्य मॉडल होता है। उनके लिए एफ # से आगे बढ़ना निश्चित रूप से बहुत प्रयास की आवश्यकता है, और यह कुछ लोगों को रोकता है। मेरे अनुभव में, F # सीखना बहुत आसान है अगर थोड़ी देर के लिए आप OOP के बारे में सब कुछ भूल जाते हैं। अन्यथा, आप C # से F # सभी प्रकार की चीजों को स्थानांतरित करना शुरू करते हैं।

समय के लिए, दो सप्ताह के प्रशिक्षण में कहीं न कहीं काम कोड लिखना शुरू करना पहले से ही संभव है, और भाषा के उपयोग में कमोबेश कई महीने लग जाएंगे। अंत में, स्वामित्व के एक अच्छे स्तर के लिए आपको अधिक समय, 6 महीने, शायद अधिक - की आवश्यकता है, अगर हम सभी पुस्तकालयों, मुहावरों और इस तरह से छंटनी के बारे में बात कर रहे हैं।

लेकिन ईमानदारी से, एफ # पर स्विच करना एंटिटी या डब्ल्यूपीएफ पर स्विच करने से ज्यादा मुश्किल नहीं है। उन्हें भी बहुत समय की आवश्यकता होती है। आवश्यक प्रयासों को कम मत समझो, लेकिन कभी-कभी वे कहते हैं कि इस संक्रमण में वर्षों लगते हैं। मैं दोहराता हूं: कोड लिखना शुरू करने के लिए, आरामदायक होने में कई सप्ताह लगते हैं - कई महीने। मैं यह दोनों अपने अनुभव से कहता हूं और अन्य लोगों के अनुभव से, जिनके साथ मैंने बात की थी।

क्या मुझे F # से पहले C # जानना होगा

- यह स्पष्ट है कि F # का उपयोग करने वालों में से अधिकांश C # से आए थे। क्या ऐसे कई लोग हैं जो C # अनुभव के बिना F # आते हैं?

- ऐसे बहुत सारे लोग नहीं हैं, और यह उनके लिए काफी कठिन है, क्योंकि सभी पुस्तकालयों में C # के लिए प्रलेखन है, इसलिए हर जगह लोग C # के उदाहरणों में आते हैं। लेकिन अभी भी ऐसे लोग हैं, और इसके अलावा, कई विश्वविद्यालयों में एफ # पढ़ाया जाता है।

ऐसे लोग हैं जो अजगर के बाद एफ # सीखने की कोशिश कर रहे हैं। समस्या यह है कि F # .NET पर बहुत निर्भर है, और .NET C # से बंधा है। विजुअल बेसिक के साथ भी यही स्थिति, C # में सभी उदाहरण हैं। आइए आशा करते हैं कि अगले कुछ वर्षों में यह स्थिति बदल जाएगी और भाषा को सीखना आसान बना देगा, अब यह महत्वपूर्ण समस्याओं में से एक है।

— C#, F#, , F# . ? LINQ , , , ?

— , , , , , : ? ? . , , , . , , , F# , Programming Theory Concepts - .

— C# , F# ?

— . , . , , . , - , Python JavaScript, .

, . JavaScript , F# . , . F# — , , C#, . F# .

— F# — «F# for fun and profit»? C#?

— F#, . F#, . , , Railway Oriented Programming, Property Based Testing . , TypeScript Ruby, , F#. , , C#.

Fun and profit

— «F# » («F# for fun and profit») - , «». , -, ?

— . . , F# , , . , , F#, , . F# .

- , — . , - Java . , , , . , , F# C# .

— «»: , , , .

— , . , , , . .

StackOverflow , , F# , . , , , , C#. , - , , 10 . .

, , F#, F#. F#, , . , . , F# .

— , F# . ? , , F# . F# ?

— , F# . , . - , . , , , . , . F# null; , ; . F# .

, F#, , , . C# — Visitor, Factory, Singleton, Bridge, F# , , , .

- . , , . , , , , , . Google Amazon — .

— , F# , — , , . ?

— , . , , C# , , C#. , C#, null, , - . F# . , , , .

- - , , , . C# F#, , , . , , . , , F#, .

— , Microsoft F# ( C# ). ?

— , Microsoft C#. , . — , Microsoft, , , Entity Framework Visual Studio. , Microsoft, Microsoft - — . , , Python Ruby. - , - , .

, F#, , , — F# , . Microsoft, . , Ionide, VS. , F# , Microsoft. , , , , , Microsoft . Microsoft , , .

— Haskell. F# — .NET-, ?

— , - , , Smalltalk, - . F# - , .NET. Java, Scala . , , C#, Java, F# , Scala, .

Haskell, . Haskell , , F#. F# , Haskell . , , , API Java, .NET JavaScript. API .NET , , API .

— . F#, , : , , ?

— , F# . , , , . , . F# , , C#. , Haskell, - , .

, , , .

F# , , . , -, .

, - , , — , ? , , , . F#, C#, , . . - , F#.

, F# , , .

DotNext «The Power of Composition». , F#: , , , . , .