PHP के भविष्य पर एक राय

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

पिछड़ी संगतता के बारे में

मेरा मानना ​​है कि प्रत्येक अगली रिलीज को पिछले एक: 6, 7, 99, "हाथी उत्साही" के साथ पिछड़ी संगतता बनाए रखने की आवश्यकता है - जो भी आपको पसंद हो उसे कॉल करें। और अब मैं "ज्यादातर" कहूंगा, क्योंकि कुछ असंगतताएं अभी भी होंगी। लेकिन इन असंगतताओं को उचित और नियंत्रित किया जाना चाहिए। उन्हें केवल सीमावर्ती मामलों और सभी के व्यवहार की समीक्षा करना चाहिए। हालांकि इसका मतलब यह नहीं है कि चीजों की शुद्धता और सादगी के लिए कोई गंभीर आंतरिक पुनर्गठन और प्रयास नहीं हो सकता है। इसका मतलब है कि असंगति डेवलपर्स को बाधित नहीं करना चाहिए।



इस दृष्टिकोण को सत्यापित करना बहुत आसान है:

आपके द्वारा लिखा गया कोड PHP 5.x और PHP 6.x (और किसी भी लगातार दो प्रमुख रिलीज) में समस्याओं के बिना चलना चाहिए।

यह महत्वपूर्ण क्यों है? PHP 4 से PHP 5. के संक्रमण पर एक नज़र डालें। प्रोग्रामर के लिए कोड लिखना आसान था जो दोनों संस्करणों पर काम करता था, हालाँकि PHP 5 में अंतिम संक्रमण लगभग 10 साल का था। और कल्पना करें, अगर ऐसा करना मुश्किल था?



यद्यपि, जैसा कि यह पता चला है, कुछ भी प्रस्तुत करने की आवश्यकता नहीं है। ठीक यही हाल पायथन का हुआ। पायथन 3 की पहली रिलीज़ लगभग 5 साल पहले हुई थी। और आज, 2014 में, वह अभी भी पूरी तरह से व्यस्त नहीं है। इसलिए नहीं कि यह खराब है, बल्कि इसलिए कि एक एकल कोड का उपयोग करना बहुत मुश्किल है जो दोनों संस्करणों पर समस्याओं के बिना काम करेगा। यही है, आप या तो पायथन 2 का उपयोग करते हैं, या इसकी कार्यक्षमता जो पायथन 3 में काम करेगी (परिणामस्वरूप, दोनों के फायदे खोते हुए)। और अगर आपको जिन पुस्तकालयों या प्लेटफार्मों की आवश्यकता है, उनमें पायथन 3 के लिए एक संस्करण नहीं है, तो आपको बस या तो उन्हें खुद को पोर्ट करना होगा, या अच्छी तरह से ... आप बस भाग्य से बाहर हैं। वास्तव में, ऐसा ही होता है।



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

इंजन को फिर से लिखने के बारे में

बहुत से लोग कहते हैं: आपको PHP इंजन को फिर से लिखना होगा। इस तथ्य के बावजूद कि मैं निश्चित रूप से इसे प्लस के रूप में देखता हूं (हां, इंजन बहुत परिष्कृत है), मुझे एक सवाल पूछना होगा: क्या यह वास्तव में आवश्यक है? मौलिक कुत्ता कहाँ दफनाया गया है? निश्चित रूप से, PHP इंजन में आर्किटेक्चरल मिसकल्चुलेशन होते हैं, लेकिन बड़े और अच्छे से काम करता है।



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



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



इसलिए फिर से लिखने की जरूरत नहीं है। रिफैक्टर और साफ।

वस्तु-उन्मुख दृष्टिकोण के लिए मानक पुस्तकालय के संक्रमण के बारे में

कुछ लोग मानक PHP लाइब्रेरी को ऑब्जेक्ट-ओरिएंटेड दृष्टिकोण पर ले जाने का सुझाव देते हैं: यहां तक ​​कि स्केलर के प्रकारों में ऑब्जेक्ट व्यवहार होगा। अर्थात्, आप निम्नलिखित कुछ लिख सकते हैं:

$string = "Foo"; var_dump($string->length); // 3 var_dump($string->toLower()); // string(3) "foo" // etc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मुझे नहीं लगता कि ऐसा होने की आवश्यकता है, हालांकि मैं मानता हूं कि यह अच्छा लगता है।



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



हालांकि, ऐसी स्थितियों को अधिक विशिष्ट व्यवहार द्वारा हल किया जा सकता है। उदाहरण के लिए, आप "गंदे" प्रकार की कास्टिंग की कोशिश करते समय एक कैच चेतावनी या एक अपवाद फेंक सकते हैं, इसलिए यदि किसी ने "123abc" को पूर्णांक में डालने का प्रयास किया, तो आपको आंशिक डेटा हानि के बारे में एक संदेश प्राप्त होगा।



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



इस प्रकार, इसका मतलब यह है कि एक वस्तु-उन्मुख दृष्टिकोण के साथ, सभी स्केलर संचालन सभी स्केलर प्रकारों के लिए बाध्य होना चाहिए। जो एक ऑब्जेक्ट मॉडल की ओर ले जाएगा जिसमें स्केलर्स में न केवल गणितीय तरीके होंगे, बल्कि स्ट्रिंग्स के साथ काम करने के तरीके भी होंगे। क्या बकवास है ...

HHVM बनना

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

1. HHVM को एक कंपनी द्वारा नियंत्रित किया जाता है। मुझे गलत मत समझो, समस्या यह नहीं है कि फेसबुक विकास पर बहुत पैसा खर्च करता है। लेकिन तथ्य यह है कि परियोजना एक कंपनी द्वारा नियंत्रित की जाती है जिसका व्यवसाय इस बात पर निर्भर नहीं करता है कि आप एचएचवीएम का उपयोग करते हैं या नहीं। यह एक बात है अगर उन्होंने सहायाता प्रदान की और HHVM को पूर्ण उत्पाद बनाया। एक और - कि अब यह न तो एक ओपन सोर्स प्रोजेक्ट है, न ही कोई कमर्शियल प्रोजेक्ट - बीच में कुछ। और ऐसी स्थिति में HHVM में उत्पादन का अनुवाद करते समय मैं बहुत तनाव में रहूंगा।
2. एचएचवीएम में एक सार्वजनिक विनिर्देश नहीं है, अर्थात, सामान्य रूप से, आप उसी तरह से प्रोग्राम करेंगे जैसे कि ज़ेंड इंजन के तहत। हालाँकि, यह एक परीक्षण और त्रुटि विधि है, क्योंकि जब तक आप कई कार्यान्वयनों का समर्थन करने का प्रयास नहीं करेंगे, तब तक सब कुछ ठीक रहेगा। एक पुस्तकालय डेवलपर के रूप में, मैंने पहले से ही अपनी त्वचा में इसे महसूस किया था। दूसरी ओर, अगर HHVM और PHP अंततः कुछ सामान्य विनिर्देशन में आए, तो कई चीजें बहुत सरल हो जाएंगी ...
3. एचएचवीएम एक बंद स्रोत परियोजना है, हालांकि यह तीसरे पक्ष के डेवलपर्स (पहले से ही अच्छा) से कोड स्वीकार करता है। हालाँकि, पुल अनुरोध और पैच स्ट्रीम एक ओपन सोर्स प्रोजेक्ट का उत्पादन नहीं करता है। खैर, प्रक्रिया की स्पष्टता कहां है? दृष्टिकोण की स्पष्टता कहाँ है? सहभागिता का खुलापन कहाँ है? नेतृत्व कहां है?

साथ ही, मुझे पता है कि मैं अपनी राय में अकेला नहीं हूं। एचएचवीएम भविष्य में एक मजबूत दावेदार होगा, लेकिन मेरा मानना ​​है कि जब तक उपरोक्त मुद्दों को हल नहीं किया जाता है, तब तक व्यावसायिक उत्पादन में एचएचवीएम का समय नहीं आया है।

क्या PHP और HHVM सह-कलाकार हो सकते हैं?

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



मुझे दोहराने दें कि परीक्षण जो वास्तविक सिस्टम का उपयोग नहीं करते हैं वे बेकार हैं: यह बकवास है और इससे भी बदतर - वे बस खतरनाक हैं।



व्यवहार में, ऐसे कार्य हैं जो HHVM PHP की तुलना में बहुत तेजी से संभाल सकते हैं। लेकिन एक ही समय में ऐसे कार्य हैं जहां PHP अपनी गति दिखाएगा। जाँच करने का एकमात्र तरीका अपने आवेदन का परीक्षण करना है।



लेकिन HHVM मेरे कोड को मूल के रूप में निष्पादित करता है! PHP कैसे तेज हो सकता है?

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



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



जब चेक एक गलत परिणाम देता है, तो "फेलओवर" जैसा कुछ होता है। सीधे शब्दों में कहें, इंजन "कैंसिल" वह सब कुछ जो इस पद्धति के लिए संकलित करता है और दुभाषिया मोड पर स्विच करता है। इस तरह के ऑपरेशन को अंजाम देना दुभाषिया मोड में निरंतर काम की तुलना में बहुत अधिक महंगा है।



और यह सिर्फ एक कारण है जेआईटी कंपाइलर्स जादू नहीं हैं।



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



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



लेकिन हैक शांत है!

हैक फेसबुक द्वारा विकसित और एचएचवीएम में शामिल एक नई प्रोग्रामिंग भाषा है। मोटे तौर पर, यह कुछ अतिरिक्त सुविधाओं के साथ PHP का एक सांख्यिकीय रूप से टाइप किया गया संस्करण है ...



और हैक कमाल का है! मैं वास्तव में चाहता हूँ कि HHVM समस्याओं को मैंने किसी तरह हल करने का संकेत दिया है, और मैं योगदान कर सकता हूँ!



आखिरकार, यह एक दिलचस्प विचार है। अब PHP के आधार पर निर्मित कई मेटलुंगेज हैं। नेता हैक और जेफिर हैं। लेकिन एक समस्या है। दोनों एक विशिष्ट रनटाइम के लिए हैं: हैक एचएचवीएम पर चलता है, और जेफिर पीएचपी पर चलता है। इसे कैसे हल करें?



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

भाषा विनिर्देश के बारे में

आपने शायद गौर किया कि मैंने पहले ही भाषा विनिर्देश की आवश्यकता के बारे में पाठ में कई बार उल्लेख किया है ...

मैं संकेत देता हूं कि यह सबसे महत्वपूर्ण चीज है जो PHP के भविष्य को भाषा, मंच, पारिस्थितिकी तंत्र और समुदाय के रूप में बेहतर बनाने में मदद कर सकती है।

संक्षेप में कहना

PHP अपने विकास के एक बहुत ही दिलचस्प चरण में प्रवेश कर रही है। लोग शांत चीजें लिखते हैं, प्रगति करते हैं। इसलिए अगर हम PHP के और विकास चाहते हैं, तो मुझे लगता है कि हमें यह अच्छी तरह से समझना चाहिए कि इस या उस विकल्प को बनाते समय हम क्या कर रहे हैं।