फ़ंक्शनल प्रोग्रामिंग सॉफ़्टवेयर डेवलपमेंट का भविष्य क्यों होनी चाहिए

• "फ़ंक्शनल प्रोग्रामिंग (FP) सीखना कठिन है, लेकिन यह आपके कोड में अप्रिय सरप्राइज़ कम कर देगी"
• FP में "less is more"
• (Maybe/Option के साथ) Null Reference समस्या का समाधान
• FP की learning curve काफ़ी steep है
• FP का भविष्य
  • कम डेवलपर्स के साथ ज़्यादा डेवलपमेंट करने के लिए हमें हर संभव टूल का उपयोग करना चाहिए, और FP इसके लिए एक टिकट है
  • हमारी जैसी कम ग्लैमरस कंपनियों के लिए डेवलपर हायर करना मुश्किल है। लेकिन ऐसे top-tier डेवलपर्स को हायर करना संभव हो जाता है जो FP codebase पर काम करना चाहते हैं
  • FP अपनाने से quality और robustness बेहतर होंगे, और उन bugs पर लगने वाला समय कम होगा जो FP में पैदा ही नहीं होते
  • मुख्यधारा की भाषाओं में FP की सुविधाएँ धीरे-धीरे दिखना शुरू होना इस बात का संकेत है कि सॉफ़्टवेयर इंडस्ट्री paradigm shift की तैयारी कर रही है
  • इंडस्ट्री को पूरी तरह बदलने में अभी बहुत काम बाकी है, लेकिन ऐसा करने के फ़ायदे इतने स्पष्ट हैं कि यह कहाँ जा रही है, इस पर संदेह की कोई वजह नहीं है

[bichi]

ऐसा लगता है कि learning curve वाकई काफी ऊँची है। टिप्पणियों में भी ऐसी बातें हैं जो दिखाती हैं कि कुछ लोग वास्तव में functional programming को पूरी तरह नहीं जानते। बेशक, कुछ टिप्पणियाँ ऐसे लोगों ने भी लिखी हैं जो इसे अच्छी तरह समझते हैं। functional programming कठिन है। मैं भी अभी तक इसे पढ़ ही रहा हूँ, आह...

[roxie]

जब प्रोग्रामिंग भाषा अब डेवलपमेंट टीम की पसंद का नहीं, बल्कि कंपनी के अस्तित्व का सवाल बनने लगेगी, तभी हम FP की आवश्यकता पर फिर से बात कर सकेंगे।

[glacks0224]

मैं इसे संक्षेप में कहूँगा। मेमोरी मैनेजमेंट और कुछ algorithms में यह अभी भी object-oriented programming से आगे नहीं निकल पाया है। स्थिति और लागत के अनुसार इसे उपयुक्त रूप से इस्तेमाल करना चाहिए।

[nallwhy]

उम्.. मैं इस दावे से सहमत नहीं हूँ कि learning curve बहुत steep है

सबसे पहले, यह बस आसान है, गलती की गुंजाइश कम हो जाती है, और इसलिए productivity बढ़ती है।
बस, वही काफी है

[ioboy]

इंसानी सोच और काम को pure functional programming languages की तरह पूरी तरह formalize करना मुश्किल है। free monad जैसी चीज़ें देखें तो लगता है कि ज़्यादा से ज़्यादा rxjs तक ही स्वीकार्य सीमा है।
FP में भी एक ऐसा मोड़ आता है जहाँ लागत से ज़्यादा जटिलता बढ़ जाती है।
मौजूदा FP effects भी बस data और methods को अलग करने भर तक ही सीमित हैं,
और सिर्फ़ यह देखकर कि Optional भी उम्मीद से कम इस्तेमाल होता है, लगता है कि type abstraction अनावश्यक abstraction है (types मिलाने में productivity बहुत घटती है)।
जब तक Clojure की तरह data और operations को और अधिक abstract करने की दिशा न हो, मौजूदा भाषाओं का उपयोग करने में सीमाएँ हैं।

[kunggom]

अपरिवर्तनीयता functional programming paradigm में अक्सर इस्तेमाल होने वाला सिर्फ़ एक टूल है।
जहाँ तक मैं समझता हूँ, functional programming paradigm ऐसा programming paradigm है जो ‘side effects’ को जितना संभव हो उतना नियंत्रित करना चाहता है।
side effects को नियंत्रित करने की कोशिश करते हुए स्वाभाविक रूप से referential transparency, immutability और pure functions जैसी बातों को महत्व दिया जाता है।

इस नज़रिए से देखें तो, भले ही आप कोई functional programming language इस्तेमाल न करें, फिर भी अपने द्वारा लिखे गए function या method के side effects को स्पष्ट रूप से समझना और उन्हें उचित तरीके से नियंत्रित करना वांछनीय है। इससे code smell कम होते हैं, unit test लिखना आसान हो जाता है, और ऐसे कई फायदे मिलते हैं।

इस विषय पर थोड़ा और विस्तार से समझाने वाले कुछ अनूदित लेख भी हैं।

• (अनुवाद) functional programming क्या है?
• (अनुवाद) कौन-कौन सी programming languages functional हैं?

इसी दृष्टिकोण से side effects को न्यूनतम करने वाली refactoring पर केंद्रित एक किताब है Soksok Deureooneun Hamsuhyeong Coding: Simplehan Codeuro Bokjaphan Software Gildeurigi। यह सिद्धांत से ज़्यादा व्यावहारिक और वास्तविक कामकाजी नज़रिए से विषय को पकड़ती है, इसलिए जो कोई अच्छा code लिखना चाहता है, उसके लिए इसे पढ़ना और सीखना पूरी तरह सार्थक है। मेरा मानना है कि इसे पढ़ने के बाद अगर code लिखते समय आप पहले की तुलना में side effects पर कहीं ज़्यादा ध्यान देने लगें, तो भी यह किताब अपनी कीमत वसूल करा देती है।

[loblue]

धन्यवाद, इसे ढूंढकर पढ़ना पड़ेगा।

[junghan0611]

आह! इसका अनुवादित संस्करण आ चुका था! मुझे इसे पढ़ना होगा!

[s0400615]

किताब की सिफारिश के लिए धन्यवाद!! मैं इसे अभी खरीदकर पढ़ूंगा!

[heal9179]

वह किताब सच में बहुत अच्छी थी!
रिफैक्टरिंग के नज़रिए से देखो तो इसे लिखना भी बहुत आसान लगता है।

[cghzjnyb7pclmlm5]

बिलकुल, मुझे भी लगता है कि functional programming एक अच्छा तरीका है, लेकिन इसके फ़ायदे लोगों तक असरदार ढंग से पहुँचाने वाले लोग ज़्यादा नहीं दिखते। सिर्फ़ यह कह देने से कि यह अच्छा है, बात उतनी समझ में नहीं आती, है ना?

आगे मेरी निजी राय है: आधुनिक ज़माने के सारे प्रोग्राम असल में Turing machine आधारित होते हैं, इसलिए अमूर्त स्तर पर उन्हें मोटे तौर पर function और data में बाँटा जा सकता है। इस वजह से मुझे लगता है कि procedural programming भी मूल रूप से functional ही है। फिर procedural की तुलना में functional का असली फ़ायदा क्या है? मेरे हिसाब से वह बस इतना है कि 'global या उसके समान दायरे के variables का इस्तेमाल न करना'। इसी फ़ायदे की वजह से 'functions के बीच isolation' और 'multi-thread computing' में भी यह असरदार होता है।

लेकिन क्या यह फ़ायदा सिर्फ़ functional programming से ही मिल सकता है? ऐसा नहीं है। Procedural languages में भी dependency injection की अवधारणा के ज़रिए class और function unit isolation को बढ़ावा दिया जाता है (और modern frameworks तो इसे पहले से ही बुनियादी रूप में अपनाते हैं), और Rust language में तो language-level restrictions के ज़रिए सुविधाजनक concurrent computing को साधने की कोशिश की गई है।

सारांश यह है कि functional languages अच्छे languages हैं और एक अच्छी methodology भी हैं, लेकिन 'evolutionary अर्थ में श्रेष्ठ' होने के बजाय, मेरे हिसाब से वे Go या Rust जैसी भाषाओं की तरह बस ऐसी भाषाएँ हैं जो 'असफल होने की संभावना को language level पर हटाने की कोशिश करती हैं, जबकि इस्तेमाल में आसान नहीं होतीं'।

[alucard]

क्या आपका मतलब है कि procedural language में भी function composition जैसी चीज़ें संभव हैं?

[cghzjnyb7pclmlm5]

'function composition' की परिभाषा को संकीर्ण अर्थ में देखें तो लग सकता है कि यह केवल functional languages में ही संभव है, लेकिन थोड़ा सोचें तो उसका execution भी आखिरकार procedural languages जैसे machine language या assembly language के ऊपर ही चलता है। यानी यह 'संभव, असंभव' का नहीं, बल्कि 'भाषा की concerns, पसंद और philosophy' का सवाल है। अगर function composition की परिभाषा को संकीर्ण अर्थ में 'किसी खास language की खास feature' के बजाय व्यापक अर्थ में 'तार्किक functions के बीच composition' के रूप में देखें, तो यह पूरी तरह संभव है। और functional languages के फायदे स्पष्ट रूप से मौजूद हैं, इसलिए rxjs या spark जैसी चीज़ों ने इन्हें सक्रिय रूप से अपनाया है.

जैसा कि हम सबने CS में पढ़ा है, नीचे दिए गए उदाहरण एक ही परिणाम देते हैं, बस उनकी expression form अलग है। और prefix notation को अक्सर functional कहा जाता है।

prefix notation : + 1 1
infix notation : 1 + 1
postfix notation : 1 1 +