जावा से स्कैला (क्लोजर, हास्केल, एरलंग ..) की अदला-बदली, प्रोग्रामिंग अमूर्तता में वृद्धि के रूप में

और स्कैला में क्या लिखा जा सकता है, जो जावा में संभव नहीं है?
(मेरे एक दोस्त, एक व्यक्ति और एक प्रोग्रामर के साथ बातचीत से)

एक नई प्रोग्रामिंग भाषा सीखने का सबसे अच्छा कारण अलग तरह से सोचना सीखना है।
चाड fowler

मैं आपको जावा के साथ तुलना में स्काला निर्माण की सादगी के बारे में नहीं बताना चाहता हूं और इस तथ्य के बारे में नहीं है कि स्काला की 1 पंक्ति में मैं जावा की 20 लाइनों को फिट कर सकता हूं । इसके विपरीत, गहरी खुदाई करें, पीएलओ की नींव को गिराएं और कुलीन जनता की प्रतिक्रिया को देखें।

शाब्दिक रूप से 1.5-2 महीने पहले, मैंने खुद से बिल्कुल वही सवाल पूछा था जो शीर्षक के तहत है। और हाल ही में, मैंने आखिरकार हमारे शेक्सपियर मार्टिन ओडस्की के उलजाम में अपनी बंदूक घुमाई । इस बिंदु पर, अनुभव के साथ कठोर स्काला प्रोग्रामर कृपापूर्वक मुस्कुरा सकते हैं, एक वर्ष के बिना एक सप्ताह कह सकते हैं, और स्काला लेख लिख सकते हैं। हाँ, हबर में भी। और फिर भी, मुझे जारी रखने दें - शायद आप निर्लिप्त नहीं होंगे।
मैं दूर से शुरू करूंगा, एक बयानबाजी के साथ: मानवता की प्रगति किस पर आधारित है? खैर, या कम से कम खुद को प्रोग्रामिंग भाषाओं तक सीमित रखें। यदि आप वाक्य रचना, विराम चिह्न से खुदाई करते हैं और जड़ को निहारते हैं? ठीक है, हां, बिल्कुल - अमूर्तता के स्तर को बढ़ाने के लिए।
जब उन्होंने मशीन कोड से मशीन असेंबलर पर स्विच किया, तो लेखन बेहतर हो गया, लेखन अधिक मजेदार हो गया।
और asm बनाम बेसिक क्या है? यह एक बढ़ई बनाम एक बढ़ई, एक कुत्ते बनाम एक आदमी की तरह है। प्रोग्रामर ने रजिस्टरों के उपकरण को जानना बंद कर दिया, वह चर में सोचने लगा! हम इस उच्च पेशे के प्रसार के भयानक दुष्प्रभाव को छोड़ देंगे, जब प्रत्येक भारतीय छात्र खुद को एक प्रोग्रामर कह सकता है।
ज्यादा है। फोरट्रान दिखाई दिया, प्रक्रियात्मक प्रोग्रामिंग, औपचारिक और वास्तविक चर, प्रक्रिया पुस्तकालय! 3 ट्रॉक्स के लिए ट्राम द्वारा यात्रा करने वाले को शायद स्पेगेटी कोड और गोटो की निरंतर सूची याद है।
अगला चरण: डेटा संरचनाएँ। चरों के साथ सोचना बंद करो! संरचना की वस्तुएं दें! यदि आप OOP की शैली में लिखते हैं और कुछ स्थानों पर आदिम में पर्ची करते हैं, उदाहरण के लिए, कैश या कॉन्फ़िगरेशन में, कई बार मैं इस पार आया हूं - इसके बारे में सोचें। क्या आप अपनी भाषा के साथ अमूर्तता के समान स्तर पर हैं? OOP आपको अपने कार्य - वस्तुओं के व्यवसाय मॉडल में सोचने की अनुमति देता है। कहने की ज़रूरत नहीं है: लेखक ए को लेखक बी, तिथि ए को तिथि बी, और टिप्पणी ए को टिप्पणी बी आदि के लिए कॉपी करें। कहो - दस्तावेज़ बी को दस्तावेज़ बी की प्रतिलिपि बनाएँ। यहां तक ​​कि अगर नीचे के क्षेत्रों की एक प्रति है, तो प्रोग्रामर सोचता है कि दस्तावेज पहले से ही दस्तावेज हैं, न कि उसके क्षेत्र।
इस पर, मैं प्रचलित परिचय को समाप्त करता हूं और शुरुआत में आगे बढ़ता हूं:

इन कार्यात्मक भाषाओं में यह किस तरह का अमूर्तता है, जो अनिवार्यता में नहीं है?

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

यह निर्धारित करें कि अनुक्रम में 2 से sqrt (N) में कोई संख्या है जैसे कि N को उसके द्वारा विभाजित करना पूरी तरह से खाली होगा।

Ff, जावेद सही बात कहेगा और करेगा:

int sqrt=(int) Math.sqrt(N); //   ,       for(int i=2; i<=sqrt; i++){ if( N % i ==0){ return false; } } return true; 

यदि आप अब यह सवाल पूछते हैं कि उसने किस तरह का अमूर्त विचार किया था, तो वह आसानी से जवाब देगा: एक चक्र में अपने सिर के साथ और काउंटर पर एक ऑपरेशन के साथ।
और अब चरमोत्कर्ष: एक कार्यात्मक प्रोग्रामर इतना उथला नहीं सोचेगा। यह Sacla कोड शब्दशः में एक कार्य का अनुवाद कर सकता है (वही उत्तर हैबे पर टिप्पणियों में है):

  !(2 to math.sqrt(N).toInt).exists(N % _ == 0) 

क्या यह सुंदर है? हां, बिना शर्त, लेकिन ... शायद यह किसी को मना लेगा, निश्चित रूप से ... ठीक है, उन लोगों के लिए, जो संदेह करते हैं, मैं संग्रह में अस्थिर ओओपी: समरूप संचालन के कारण उनके सिर के पिछले नाखून को अपने हाथों में ढंकने की कोशिश करूंगा । एक छोटे से 3-अक्षर वाले शब्द में, स्काला प्रोग्रामर जावा को किसी भी संग्रह पर संगणना को समानांतर करने के लिए भेज सकता है। उदाहरण के लिए, इस तरह:

 !(2 to math.sqrt(N).toInt).par.exists(N % _ == 0) 

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

---

• स्कैला क्यों सीखते हैं
• स्कैला में प्रोग्रामिंग, दूसरा संस्करण