PHP अब उतना बुरा (Suck) नहीं है

 (developerjoy.co)
10 पॉइंट द्वारा GN⁺ 2024-05-08 | 40 टिप्पणियां | WhatsApp पर शेयर करें
  • "PHP बुरा है (PHP Sucks)" जैसी ज़्यादातर आलोचनाएँ इसलिए हैं क्योंकि उन्होंने 2012 के बाद वाला PHP देखा ही नहीं
  • PHP 5.4 के बाद बहुत बदलाव हुए हैं, और उसके बाद हुए language changes को देखना ज़रूरी है

PHP 5.4 के बाद के मुख्य बदलाव

  • Traits (PHP 5.4)
    • inheritance की जगह composition का इस्तेमाल करने में मदद करता है
    • traits को किसी भी class में शामिल किया जा सकता है
  • संक्षिप्त array syntax
    • array() लिखने की ज़रूरत नहीं, square brackets का इस्तेमाल किया जा सकता है
  • array destructuring
    • array को किसी अस्थायी variable में डाले बिना सीधे variables में assign किया जा सकता है
  • first-class variadic functions
    • ... syntax का उपयोग करके function में जितने चाहें उतने arguments भेजे जा सकते हैं
  • generators
    • memory-intensive कामों को अधिक memory-efficient तरीके से किया जा सकता है
  • anonymous classes
    • नई file बनाए बिना नई class बनाई जा सकती है
    • दूसरी classes की तरह interfaces भी implement कर सकती है

PHP 7 के बाद के मुख्य बदलाव

  • trailing commas
    • function call या method call में trailing comma जोड़ने को लेकर अब अनावश्यक झंझट नहीं
  • arrow functions
    • JavaScript से थोड़ा अलग है, लेकिन language में एक अच्छा addition है
  • Null coalescing operator
    • value assign करने से पहले null check करने की ज़रूरत नहीं
  • Null coalescing assignment operator (PHP 7.4)
    • null coalescing operator का एक shorthand assignment version भी है
  • Weak maps (PHP 7.4)
    • memory के लिहाज़ से arrays से काफ़ी बेहतर
    • objects को key के रूप में इस्तेमाल किया जा सकता है

PHP 8 के बाद के बदलाव

  • Null-safe operator
    • method call करने से पहले null check करने की ज़रूरत नहीं
  • named arguments
    • optional arguments को skip करने के लिए null का इस्तेमाल करने की ज़रूरत नहीं
  • attributes (annotations)
    • class, method, argument या property में annotations जोड़ने के लिए इस्तेमाल किया जा सकता है
  • बेहतर error handling
    • false लौटाने के लिए exception variable की ज़रूरत नहीं
  • match expression
    • लंबे switch statements की जगह अधिक संक्षिप्त और पढ़ने में आसान तरीका
  • Enums (PHP 8.1)
    • values और methods वाले enum classes बनाई जा सकती हैं
    • type hint के रूप में भी इस्तेमाल किया जा सकता है
  • type safety
    • typed arguments, return types, union types, intersection types आदि उपलब्ध हैं
    • enum के लिए type hint भी इस्तेमाल किया जा सकता है
  • constructor property promotion (PHP 8.0)
    • अब लंबे-चौड़े constructors की ज़रूरत नहीं
    • boilerplate code कम करने में मदद मिलती है
  • readonly properties (PHP 8.1)
    • properties को read-only चिह्नित करने के लिए keyword declaration संभव है

प्रदर्शन

  • PHP 5.6 से 7 में जाने पर 400% performance improvement
  • PHP 7 से 8 में जाने पर 20% performance improvement
  • ज़्यादातर web development use cases के लिए पर्याप्त performance देता है, और इससे अधिक विशेष उपयोगों के लिए किसी specialized language की सिफ़ारिश की जाती है

निष्कर्ष

  • PHP मरा नहीं है, और अब सबसे खराब भी नहीं है। 2012 के बाद language में काफ़ी बदलाव आए हैं, और अब इस पर अपनी राय बदलने का समय है।
  • traits, संक्षिप्त array syntax, array destructuring जैसी कई सुविधाओं के आने से PHP अधिक efficient, readable और maintainable language बन गया है।
  • इसके साथ बेहतर error handling, attributes का परिचय, और लंबे समय से प्रतीक्षित enums के आने को जोड़ दें, तो साफ़ है कि PHP web development के लिए एक मज़बूत और भरोसेमंद विकल्प बन चुका है।
  • इसलिए अगर कोई कहता है कि PHP सबसे खराब है, तो आप भरोसे से कह सकते हैं कि वे बस अतीत में अटके हुए हैं।

GN⁺ की राय

  • PHP के language changes को देखें तो साफ़ है कि यह अब पुराना PHP नहीं रहा। फिर भी लगता है कि कई developers अब भी पुरानी धारणा में अटके हुए हैं.
  • traits, short array syntax, destructuring assignment जैसी कई सुविधाएँ जोड़ी गई हैं, जो code को अधिक संक्षिप्त और readable बनाती हैं। इससे maintainability बेहतर होने की भी उम्मीद है।
  • generators और weak maps जैसी memory efficiency बढ़ाने वाली सुविधाएँ भी ध्यान खींचती हैं। बड़े पैमाने के data processing में ये उपयोगी लगती हैं।
  • Enum और type safety में सुधार जैसी बदलावों ने language की परिपक्वता बढ़ाई है। इससे clean code लिखना और आसान हो सकता है।
  • सबसे बढ़कर PHP 8 का performance improvement प्रभावशाली है। कहा जाता है कि वास्तविक benchmark में यह NodeJS और Go के बराबरी का performance दिखाता है.
  • लेकिन legacy PHP projects को modernize करना आसान काम नहीं है। code migration में काफ़ी resources लग सकते हैं।
  • PHP आज भी WordPress जैसे कई open source ecosystems की आधारभूत language है। केवल language features देखकर PHP की value को कम करके आंकना मुश्किल है।

संबंधित पढ़ाई

40 टिप्पणियां

 
blueraven 2024-05-20

ये कमेंट्स साफ़ दिखाते हैं कि php अब भी क्यों suck करता है।
बधाई हो, वह बदबू न करने वाला गोबर बन गया है।
मौका मिले तो गोबर की जगह कुछ और भी खाकर देखिए : )
 
yangeok 2024-05-14

काफी ज़्यादा प्रतिक्रियाएँ आ रही हैं। मैं php developer नहीं हूँ। लगता है कि community में फैलाए गए php-नफ़रत वाले नज़रिए को देखकर junior लोगों में भी वैसी ही भावना बन जाती है और यह बुरा चक्र बार-बार दोहराया जाता है। एक सच्चा कारीगर कभी अपने tools को दोष नहीं देता। php developers, आप हमेशा हिम्मत बनाए रखें।
 
koxel 2024-05-11

php developer के तौर पर... दूसरी भाषाएँ इस्तेमाल करने वाले लोगों का घमंड सच में गाली निकलवा देता है।
समझ से बाहर है कि लोग दूसरों की इस्तेमाल की जाने वाली भाषा को इतना नीचा दिखाने पर क्यों तुले रहते हैं।
मैंने भी php develop करते-करते Java में switch किया है, Python भी किया है, nodejs भी किया है...
हर language में ऐसी philosophy या असुविधाएँ होती हैं जो समझ में नहीं आतीं, फिर सिर्फ php को ही गाली देने की इतनी बेचैनी क्यों है, समझ नहीं आता...
आखिर ऐसा क्यों करते हैं, कमबख्त।
जिन हालातों को php का bug कहा जाता है, असल development में
वे ऐसे syntax या structures होते हैं जिन्हें जाने बिना भी काम चल जाता है, क्योंकि उनका इस्तेमाल लगभग नहीं होता,
और ऐसी legacy दूसरी languages में भी कुछ न कुछ हद तक होती ही है।
अब तो सच में उबाऊ लगने लगा है।
 
savvykang 2024-05-15

मैं उस तकनीक के बारे में बात करने के लिए माफ़ी चाहता हूँ जिसे आप अपने पेशे के रूप में अपनाते हैं। मेरी मंशा चाहे जो भी रही हो, लेकिन नतीजतन मैंने koxel जी की भावनाओं को ठेस पहुँचाई, और उसकी ज़िम्मेदारी मेरी है.

लेकिन मैंने सिर्फ़ वही लिखा जो मैंने एक junior के रूप में काम करते हुए PHP डेवलपर्स के बीच महसूस किया, जो मानते थे कि बस raw coding ही सब कुछ है। कुछ PHP डेवलपर्स यह मानने और स्वीकार करने से भी इनकार करते हैं कि best practice भी बदलती है। वही बात मुझे परेशान करती थी। फ़िलहाल मैं मुख्य रूप से frontend इंडस्ट्री में काम करता हूँ, लेकिन मुझे लगता है कि JavaScript development methods के बारे में भी काफ़ी आलोचना की जा सकती है। मैं यह नहीं मानता कि कोई एक language पूरी तरह superior है; मेरा मानना है कि स्थिति के अनुसार अलग-अलग मानदंड लागू होने चाहिए.
 
koxel 2024-05-11

लगता है समस्या उस संरचना में है जो नए डेवलपर को गलत प्रोग्राम लिखने की अनुमति देती है
लेकिन क्या दूसरी भाषाओं में भी ऐसा नहीं होता?
हर भाषा में best practices होने की वजह भी तो यही है..
 
okkorea 2024-05-09

WordPress के अनुसार PHP 5.6 या उससे नीचे के वर्ज़न का उपयोग 5% से कम है.
https://wordpress.org/about/stats/
फिर भी 2023 में WordPress ने PHP इंस्टॉलेशन की न्यूनतम आवश्यकता 7.0 तक बढ़ा दी थी
 
cosine20 2024-05-09

मेरे हिसाब से PHP से जितनी चिढ़ है, लगभग उतनी ही Javascript से भी है.
इन दोनों के मुकाबले Python तो फिर भी काफ़ी बेहतर लगता है
 
yeppyshiba 2024-05-09

मैंने अपना करियर PHP से शुरू किया था, और लगता है कि करियर का हाई भी PHP के जरिए ही हासिल किया।
अब मैं किसी दूसरी भाषा से रोज़ी-रोटी कमा रहा हूँ, लेकिन

आज भी side project या शौक के लिए कभी-कभी PHP निकालकर देखता हूँ।

मेरे लिए यह अब भी उतना ही आकर्षक लगता है।
बेशक, आजकल कई alternatives आ गए हैं, इसलिए थोड़ा अफसोस होता है, लेकिन

Laravel Vapor अच्छा है।
 
botplaysdice 2024-05-09

मैं इस समय web development नहीं कर रहा हूँ, लेकिन पुरानी यादें ताज़ा हो गईं।

लगता है बहुत से लोग PHP को नापसंद करते हैं। मैंने भी PHP लगभग 3 साल इस्तेमाल किया था, और लगातार यही महसूस किया कि एक language के रूप में उसका आकर्षण सचमुच कम है। RoR से परिचय होने पर मैं Ruby नाम की language की खूबसूरती पर पूरी तरह मोहित हो गया था, और कह सकता हूँ कि PHP ने ही मुझे वहाँ तक पहुँचाया।

लेकिन जब PHP पहली बार आया था, तब वह कमाल का था! वह ऐसा दौर था जब CGI से bulletin board बनाए जाते थे। उस समय PHP जो फुर्ती देता था, वह सचमुच sensation था। यह सच है कि PHP ने web development के लिए एक बड़ा क्षितिज खोला था। :)

लेकिन, नई शराब नई मशक में...
 
nemorize 2024-05-08

भाषा के रूप में PHP अब भी सबसे खराब भाषाओं में से एक है,

लेकिन प्लेटफ़ॉर्म (इसके लिए सही अभिव्यक्ति ढूँढना मुश्किल है) के रूप में PHP मुझे उम्मीद से बेहतर लगता है।
खासकर MVP से शुरुआती growth stage वाले प्रोजेक्ट्स में, अगर पहले से यह तय कर दिया जाए कि बाद में किसी दूसरी language/platform/framework (आमतौर पर Spring) पर जाना है,
तो उसके बाद भाषा की कमियाँ उतनी महत्वपूर्ण नहीं रह जातीं, और PHP के फायदे ही ज़्यादा नज़र आते हैं।

सिर्फ बिना रुकावट फाइलें बदलकर भी deploy किया जा सकता है, इसलिए user feedback को ज़्यादा तेज़ी से reflect किया जा सकता है,
PHP(-FPM) का किफायती request queue handling, जो यह दूसरों की तुलना में ख़ास तौर पर अच्छी तरह करता है, अप्रत्याशित बड़े traffic (कम समय में growth) को अच्छी तरह झेलने में मदद करता है,
और bug होने पर भी पूरा app बंद नहीं होता, memory leak से भी कुछ हद तक आज़ादी रहती है, इसलिए business logic + a पर फोकस किया जा सकता है,
यहाँ तक कि जिन developers ने कभी PHP इस्तेमाल नहीं किया, और जिनकी main language कोई दूसरी है, वे भी एक हफ़्ता देखकर काफ़ी हद तक इसे इस्तेमाल कर सकते हैं — इतनी आसान difficulty तक...

ये सब scale बड़ा होने पर (शायद गंभीर) नुकसान बनकर लौट सकते हैं...
लेकिन कम से कम MVP scale पर, जहाँ user feedback लेकर तुरंत लागू करना है और तेज़ी से grow करना है, वहाँ PHP जितना उपयुक्त विकल्प क्या कोई और है?
ऊपर से, PHP अपनाने का फैसला लेते समय ही मन में यह तय है कि 'size बड़ा होने पर किसी दूसरी language में migrate करेंगे', तो फिर गंभीरता से... Why not?
 
savvykang 2024-05-09

मेरा थोड़ा अलग विचार है: अगर कोई व्यक्ति अकेले MVP बनाना चाहता है, तो उसे ऐसे टूल्स चाहिए जो कम-से-कम कोडिंग में DB schema, WAS और UI—इन तीनों को लागू कर सकें। और मुझे लगता है कि PHP के विकल्प के रूप में Ruby on Rails और Django जैसे बेहतरीन विकल्प मौजूद हैं।

Django के मामले में, अगर आप सिर्फ model class define कर दें, तो Active Record pattern (काफी पुराना शब्द है, है न) के आधार पर DB schema और बैकऑफिस के लिए कामचलाऊ CRUD UI मिल जाता है। authentication, access control, form validation, DB migration tools, test tools आदि जैसे वे साधन भी मिलते हैं जो एक न्यूनतम web service development के लिए चाहिए होते हैं। निजी तौर पर, 2000 के दशक के उत्तरार्ध में web programming शुरू करने के बाद से मैंने Django जितनी productivity कभी अनुभव नहीं की। SPA तरीका लोकप्रिय होने और frontend व backend भूमिकाओं के अलग होने के बाद तो उल्टा ऐसा भी लगता है कि productivity कम हो गई है। वजह यह है कि कम-से-कम दो लोगों को user flow समझना पड़ता है, और protocol पर तालमेल होने के बाद ही वे parallel में काम कर सकते हैं।

अगर PHP खुद को web app के लिए template language के रूप में पेश करना चाहता था, तो मेरा मानना है कि उसे language level पर web vulnerabilities से बचाव के साधन देने चाहिए थे। शायद यही बात इस बात से भी साबित होती है कि modern PHP style ने framework-आधारित development approach अपना ली है।
 
okkorea 2024-05-09

और PHP को खुद को एक general-purpose scripting language के रूप में पेश किए हुए भी काफी समय हो चुका है।
 
okkorea 2024-05-09

मुझे समझ नहीं आता कि आप language और framework की तुलना क्यों कर रहे हैं।

Ruby on Rails और Django कॉन्सेप्ट वाला Laravel भी है।
 
savvykang 2024-05-09

जब modern PHP अब "modern" न रहकर PHP के मानक development तरीके के रूप में स्थापित हो जाएगा, और WordPress सहित CMS भी modern PHP को अपनाएँगे, तब मुझे लगता है कि लोग PHP को एक सुरक्षित general-purpose language के रूप में पहचानेंगे। भरोसा बहाल करने में आम तौर पर उसे तोड़ने की तुलना में ज़्यादा मेहनत लगती है।
 
savvykang 2024-05-09

ऐसा इसलिए है क्योंकि backward compatibility बनाए रखने के नाम पर beginners को PHP की केवल basic functionality के सहारे असुरक्षित web services बनाने की अनुमति मिल जाती है। PHP tutorial खोजने पर ऊपर आने वाली 5 साइटों में से, XSS से बचाव के लिए superglobal के content को output करते समय HTML escaping लागू करना चाहिए—ऐसी बात PHP की आधिकारिक साइट के अलावा कहीं शामिल नहीं है। जब उनके द्वारा आधिकारिक रूप से दी गई guide में web development की सामग्री शामिल है, तो क्या PHP भाषा और framework—दोनों की भूमिका नहीं निभा रहा है?

superglobal variables के नामों के रूप में HTTP के कई elements built-in रूप में दिए गए हैं — इस बारे में आप क्या सोचते हैं? मेरा मानना है कि भाषा जो कुछ व्यक्त करती है, उसी के अनुसार उसकी general-purpose सीमा और उसके उपयोग के क्षेत्र तय होते हैं।
 
nemorize 2024-05-09

उदाहरण के तौर पर बताए गए $_GET, $_POST जैसे superglobal variables वे मान हैं जो PHP को CGI, SAPI मोड में इस्तेमाल करने पर expose होते हैं। PHP को CLI में इस्तेमाल करने पर ये मान expose नहीं होते।
ऐसे superglobal variables, PHP को चलाने वाले runtime जैसे PHP-CGI, PHP-FPM आदि द्वारा expose किए जाने वाले एक तरह के API हैं; यह भाषा के रूप में PHP का spec नहीं है।
पहले उल्लेख किया गया "template language होने का दावा करने वाला PHP" भी सख्ती से कहें तो PHP नहीं, बल्कि PHP के runtimes में से एक CGI है, जो चाहता है कि उसका इस तरह उपयोग किया जाए।

इसी तरह, जिन अनेक PHP built-in functions को vulnerability कहा गया था, वे भी PHP extensions द्वारा expose किए गए functions हैं, PHP नाम की "language" की मूल क्षमताएँ नहीं।

अगर आपकी बात मानें,
तो JavaScript एक ऐसी language और framework दोनों हो जाएगी जो browser से संचार करने के लिए browser द्वारा expose किए गए API का उपयोग करती है, और शुरुआत से उसी उद्देश्य से design की गई है,
Java एक language होते हुए भी वस्तुतः JDK के असंख्य API का उपयोग करने के लिए इस्तेमाल होने वाला framework बन जाएगा,
और बाकी सभी दूसरी languages को भी, उनकी अपनी spec से अलग, अगर वे standard library या API प्रदान करती हैं, तो सबको framework मानना पड़ेगा।

बेशक यह सही है कि दोनों का रिश्ता अलग नहीं किया जा सकता, लेकिन इन बातों के आधार पर PHP को framework कहना काफ़ी कमज़ोर तर्क है।
 
savvykang 2024-05-09

और मई 2024 तक भी WordPress core project में XSS का patch किया जा रहा है यह देखकर लगता है कि केवल PHP syntax स्तर पर किए गए सुधारों से XSS को रोका नहीं जा सकता।

फ्रंटएंड framework, server-side template engine आदि data के रूप में render की जा सकने वाली हर चीज़ पर एकसमान रूप से HTML escape लागू करते हैं, और केवल तब असुरक्षित तरीके से output बनाते हैं जब escape को स्पष्ट रूप से disable किया जाए। PHP में ऐसे processing को एकसमान रूप से लागू करने का कोई agreed-upon तरीका नहीं है। अगर echo या print statements में default रूप से escape support होता, तो तुरंत असर यह होता कि बहुत सारा code काम करना बंद कर देता, लेकिन लंबे समय में अधिक लोग escape छूट जाने जैसी गलतियों को कम कर पाते।
 
savvykang 2024-05-09

हाँ, मैं भाषा और runtime environment को अलग करके देखने वाले दृष्टिकोण से सहमत नहीं हूँ, और मेरा मानना है कि किसी न किसी तरह runtime environment भाषा को प्रभावित करता है। JavaScript के मामले में Node.js और browser, ये दो runtime environments हैं, और Python में कई implementations हैं, लेकिन आप इसे इस तरह समझ सकते हैं कि CPython प्रमुख है.

मूल लेख का विषय व्याकरणिक सुधारों तक सीमित है, लेकिन मैं इस फ्रेम से थोड़ा व्यापक दायरे की बात करना चाहता था
 
nemorize 2024-05-10

> साथ ही, मुझे लगता है कि Laravel ऐसी चीज़ है जिसे open source contributors ने नहीं, बल्कि Rasmus या Zend जैसी संस्थाओं ने, 2011 में नहीं बल्कि लगभग 2007 के आसपास, किसी अलग प्रोजेक्ट के रूप में नहीं बल्कि भाषा की आधिकारिक feature के रूप में लाना चाहिए था। Python 3 ने backward compatibility का कुछ हिस्सा छोड़ा था, इसलिए उसके adoption में रुकावट आई, लेकिन मेरा मानना है कि PHP को भी version 5 के आसपास backward compatibility की बड़ी सफाई करनी चाहिए थी। कभी-कभी लगता है कि PHP के बदलाव हमेशा समय के रुझान से थोड़ा पीछे आते हैं.

यह ऊपर की टिप्पणी के जवाब के रूप में भी है।

आपके बताए नज़रिए से देखें तो यह सोचा जा सकता है कि PHP को एक तरह के web framework की तरह माना जा सकता है।
लेकिन, उदाहरण के तौर पर बताए गए XSS filter, escaping वगैरह जैसे कई features PHP को default रूप से देने चाहिए, ऐसा मैं नहीं मानता।

सबसे आम PHP-FPM, Django, और RoR एक ही position में नहीं हैं। वे Flask, Sinatra, और Express के ज़्यादा क़रीब हैं।
PHP-FPM routing (directory-based), request parsing ($_GET, $_POST, $_FILE, $_COOKIE), response भेजना (echo, print), और session management ($_SESSION) से ज़्यादा की ज़िम्मेदारी नहीं लेता।

क्या Flask अलग है?
Flask में HTML-escaped response लौटाने के लिए सिर्फ return से काम नहीं चलता।
https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping

क्या Sinatra अलग है?
उसी तरह, इसमें भी अलग escaping library का इस्तेमाल करना पड़ता है।
https://sinatrarb.com/faq.html#escape_html

क्या Express अलग है?
इसमें भी यही बात है, अलग escaping library का इस्तेमाल करना पड़ता है।
https://expressjs.com/en/resources/middleware.html

उदाहरण के तौर पर बताई गई libraries में से कोई भी उस framework की आधिकारिक library नहीं है।
फिर PHP को ही ऐसी functionality आधिकारिक रूप से क्यों देनी चाहिए?

अगर कोई यह कहे कि "कौन-सा पागल framework request data को superglobal variables के रूप में expose करता है, चाहे इसमें security problem न भी हो, फिर भी यह user के प्रति शिष्ट नहीं है!" जैसे
कारणों से, जिनकी चर्चा पहले से बहुत लोग करते आए हैं, PHP बेकार है — तो अलग बात है,
लेकिन आपने जो कारण दिया, "PHP की default functionality full-stack framework जितनी पर्याप्त नहीं है" — उससे... कम-से-कम मैं सहमत होना मुश्किल पाता हूँ।

जैसे Express को थोड़ा ज़्यादा modern और व्यवस्थित तरीके से इस्तेमाल करने के लिए Nestjs नाम का दोस्त बना, वैसे ही PHP को थोड़ा ज़्यादा modern और व्यवस्थित तरीके से इस्तेमाल करने के लिए Laravel नाम का दोस्त बना — अगर ऐसा मानें...
तो क्या दूसरी frameworks (languages) से तुलना में दिखने वाली कमियों से ज़्यादा, मेरी मूल टिप्पणी के दावे की तरह, PHP(-FPM) की अपनी खास खूबियाँ ज़्यादा स्पष्ट नहीं लगेंगी?
 
savvykang 2024-05-10

पुरानी यादें ताज़ा करूँ तो लगता है कि कम से कम अगर slim और twig का कॉम्बिनेशन ही आम हो गया होता, तो प्रोजेक्ट में की गई PHP की गलतियाँ कुछ कम हो सकती थीं। बेशक, उस समय दूसरे PHP डेवलपर्स PHP में सीधे-सीधे कोड लिखने के आदी थे, इसलिए तब इसे अपनाया नहीं जा सका। शुक्र है कि PDO standard library में था, इसलिए SQL injection के खिलाफ तैयारी की जा सकती थी.

मूल कमेंट में जिस bug impact limitation या processing performance का ज़िक्र किया गया है, उस पर मेरे पास न खास नकारात्मक और न ही सकारात्मक राय है। मुझे लगता है कि ऐसी सुविधाएँ होना अच्छा है, लेकिन throughput में अचानक बढ़ोतरी या memory usage की समस्या ऐसी चीज़ें हैं जिन पर growth stage में कम से कम एक बार ज़रूर सोचना पड़ता है, इसलिए मेरा मानना है कि अगर ऐसी समस्याएँ explicit रूप में जितनी जल्दी सामने आएँ, उतना बेहतर है।
 
nemorize 2024-05-10

> बेशक, उस समय इसे अपनाया नहीं जा सका क्योंकि दूसरे PHP डेवलपर्स PHP में बिना ढंग की संरचना वाले कोडिंग के आदी थे.

> क्योंकि PHP से डेवलपमेंट करना जानने वाले लोगों को बदलना सबसे ज़्यादा समय लेने वाला और सबसे कठिन काम है

व्यक्तिगत रूप से मुझे लगता है कि PHP खुद में कोई समस्या नहीं है, या उससे निपटने के पर्याप्त साधन हैं, या फिर ऐसी भिन्नताएँ हैं जो दूसरी भाषाओं की तरह समझ में आने वाले कारणों से पैदा हुई हैं; लेकिन आपने जो manpower की समस्या कही... शायद वही वास्तव में सबसे बड़ी समस्या है.

जो डेवलपर्स PHP को गंभीरता से इस्तेमाल कर सकते थे, वे बहुत पहले पुराने PHP से ऊबकर उसे छोड़ चुके हैं,
और जो ज़्यादातर उपयोगकर्ता बचे हैं, वे ऐसे लोग हैं जो PHP कितना भी आगे बढ़ जाए, उसे ठीक से देखना ही नहीं चाहते, या ठीक से देखने की क्षमता ही नहीं रखते...

जिन MVP+a प्रोजेक्ट्स के लिए PHP उपयुक्त लगता है, उनमें पहले प्रकार के अनुभवी लोगों के शामिल होने की कोई वजह नहीं होती,
और मान लीजिए वे शामिल हो भी जाएँ, तो या तो वे PHP नहीं चुनेंगे, या PHP चुन भी लें तो दूसरे प्रकार के एक-दो यूज़र घुसते ही सब कुछ बिखर जाएगा... हाहा

कम-से-कम कोरिया में तो संतोषजनक PHP डेवलपमेंट करने वाले लोगों को खोजना ही आसान नहीं है.
इस तरह PHP फिर विकल्पों से बाहर हो जाता है, और औसत manpower level और भी गिरता जाता है, और यही अनंत दोहराव एक vicious cycle बनाता जाता है.
~~शायद इसी तरह लगातार बात फैलाकर ही सही, कम-से-कम छोटे 1~3 लोगों वाले प्रोजेक्ट्स में भी~~ ठीक से PHP प्रोजेक्ट शुरू करने के केस बढ़ने चाहिए, तभी यह vicious cycle टूटेगा, ऐसा लगता है.

हालाँकि मैं खुद भी सच कहूँ तो PHP से होने वाली कमाई इतनी बड़ी नहीं है. संतोषजनक talent supply बहुत मुश्किल है, इसलिए PHP को main stack के रूप में ले जाना चाहूँ भी तो ले जाना मुश्किल है...
 
savvykang 2024-05-10

इसका कारण यह है कि एक general-purpose language और PHP के बीच HTML पेज बनाने के तरीके में फर्क है। कम से कम 1.0 version जारी करते समय से Flask लोगों को template engine इस्तेमाल करने के लिए प्रोत्साहित करता रहा है और उसी पर निर्भर रहने के हिसाब से डिज़ाइन किया गया है। यह HTML पेज और server-side data के बीच जानबूझकर अलगाव रखता है और template unit के स्तर पर काम को सपोर्ट करता आया है। मुझे लगता है कि इसमें हल की जाने वाली समस्या की प्रकृति और लोगों की उपयोग-आदतों, दोनों को ध्यान में रखा गया है。

दूसरी ओर, PHP में standard output ही सीधे पेज का हिस्सा बन जाता है, और server-side data तथा HTML पेज के बीच की सीमा धुंधली है। जो कुछ print किया जाता है, वह वैसा का वैसा result page में चला जाता है, और escaping डेवलपर को explicitly करनी पड़ती है। हर external data के साथ htmlcharacterescapes function लगाना पड़े—ऐसा डिज़ाइन लोगों को पसंद नहीं आया। लोग अवचेतन रूप से template चाहते थे, लेकिन PHP में ऐसा लगता है कि HTML पेज बनाने के उपयोगकर्ता-उद्देश्य को पर्याप्त रूप से ध्यान में नहीं रखा गया था।

इस सुविधा का standard library या खुद language में शामिल होना इसलिए ज़रूरी है, क्योंकि PHP के environment setup और code deployment तरीके को देखते हुए यही सबसे प्रभावी तरीका है। LAMP stack के कारण development environment, और web hosting के कारण production environment, पहले से काफ़ी मानकीकृत रहे हैं, और लोग FTP से फ़ाइलें अपलोड करने के तरीके के आदी रहे हैं, इसलिए अतिरिक्त package उपलब्ध कराने की संभावना general-purpose languages की तुलना में कम है। beginners से module installation की अपेक्षा भी नहीं की जा सकती। अंत में बचता है सिर्फ standard library और standard documentation का विकल्प।
 
nemorize 2024-05-10

> लोगों ने अवचेतन रूप से टेम्पलेट चाहा होगा, लेकिन PHP में ऐसा नहीं लगता कि उपयोगकर्ता के HTML पेज बनाने के उद्देश्य को ध्यान में रखा गया था।

मुझे यह बात बहुत ज़्यादा सहमति योग्य नहीं लगती।
जैसा आपने कहा, PHP3 के दौर में, जब यह बस C API को CGI के जरिए आसानी से expose करने के स्तर का था, तब यह कहा जा सकता है कि उसका उपयोग टेम्पलेट के तौर पर होता था...

लेकिन PHP 4.2 से ही ऐसा वातावरण बन चुका था जिसमें इसे पर्याप्त रूप से एक general-purpose भाषा की तरह इस्तेमाल किया जा सकता था।
ऐसा माहौल बन गया था जहाँ यह अपेक्षा की जा सकती थी कि कोड CLI के जरिए execute होगा, और जैसा आपने पिछली टिप्पणी में कहा था कि "Laravel कोई अलग प्रोजेक्ट नहीं, बल्कि 2007 के आसपास आधिकारिक भाषा फीचर के रूप में आना चाहिए था" — यह बात उस समय के PHP के दिशा-निर्देशन से बिल्कुल मेल नहीं खाती।

2004 में जारी Smarty नाम का PHP template engine, और 2006 में जारी CodeIgniter नाम का PHP MVC framework — इनका अस्तित्व ही यह साबित करता है कि PHP स्वयं में template language नहीं था, और यह भी माना जा सकता है कि इसे उस तरह इस्तेमाल न करने को लेकर PHP समुदाय में पहले से ही एक सामाजिक सहमति बन चुकी थी।

> फ्रंटएंड framework, server-side template engine आदि render किए जा सकने वाले सभी कंटेंट पर एकसमान रूप से HTML escaping लागू करते हैं, और केवल तब असुरक्षित तरीके से output बनाते हैं जब escaping को स्पष्ट रूप से disable किया जाए।

पिछली टिप्पणी की ऊपर वाली बात भी, PHP के उस समय-संदर्भ से तुलना करें तो, मुझे खास सही नहीं लगती।
2005 में जब django पहली बार जारी हुआ, और उसके बाद भी कई सालों तक, HTML escaping default setting नहीं थी। डेवलपर को जानबूझकर escape filter सेट करना पड़ता था। आज भी Python में इस्तेमाल होने वाले jinja के मामले में HTML escaping अब तक अपने-आप नहीं होती।

जब auto escaping को सामान्य माना जाने लगा, तब तक PHP को template language की पहचान छोड़े हुए काफी समय हो चुका था। (हालाँकि उस समय PHP को बिना ज़्यादा सोचे-समझे इस्तेमाल करने वाले उपयोगकर्ता शायद यह नहीं चाहते थे, लेकिन दूसरे नज़रिए से देखें तो यह भी कहा जा सकता है कि PHP ने पहले ही तय कर लिया था कि वह ऐसे उपयोगकर्ताओं को धीरे-धीरे बाहर कर देगा।)

PHP अब उस तरह के उपयोग की भाषा नहीं है, इसलिए PHP की standard library और भाषा में ऐसी सुविधा को default value के रूप में लागू करने का कोई खास कारण नहीं था। और एक general-purpose भाषा के रूप में काम करना चाहने वाले PHP के दृष्टिकोण से देखें तो, आपने जिस htmlcharacterescapes फ़ंक्शन का उल्लेख किया, वही पहले से अपनी भूमिका पर्याप्त रूप से निभा रहा था।

> वेब होस्टिंग के तरीके से ऑपरेटिंग environment पहले से standardized होता है, और लोग FTP से फाइल डालने के तरीके के आदी होते हैं, इसलिए additional package उपलब्ध कराने की संभावना general-purpose भाषाओं की तुलना में कम होती है।

ऊपर की बात से भी मुझे ज़्यादा सहमति नहीं है। दस साल से भी पहले से git वगैरह का बहुत अच्छे से उपयोग होता रहा है। यहाँ तक कि Docker जारी होने के तुरंत बाद से ही Docker का उपयोग करके deployment की काफी कोशिशें हुईं, और आज भी ऐसा किया जा रहा है।

मुझे लगता है कि आपने जिन बातों का ज़्यादातर उल्लेख किया है, वे PHP से ज़्यादा PHP पर बने CMS के ऊपर काम करते समय ही अर्थपूर्ण लगती हैं।
मुझे इस तरह की अभिव्यक्ति पसंद नहीं, लेकिन शायद यह वही मामला है जहाँ PHP डेवलपर भी उन्हें डेवलपर मानकर नहीं देखते...
 
savvykang 2024-05-10

jinja की auto escaping सुविधा के बारे में मेरी बात गलत थी, और आपने जो कहा वह सही है.

> ऊपर की बात से भी मैं पूरी तरह सहमत होना मुश्किल पाता हूँ. दस साल से भी पहले से git वगैरह का बहुत अच्छे से उपयोग किया जाता था. यहाँ तक कि Docker के सार्वजनिक होने के तुरंत बाद से Docker का उपयोग करके deployment भी काफी किया गया था, और आज भी उसी तरह उपयोग हो रहा है.

मेरा PHP अनुभव 2014 पर ही रुका हुआ है, और उस समय Docker नहीं था. git भी इसलिए अपनाया नहीं जा सका क्योंकि काम करने का तरीका बदलना पड़ता. असल कामकाजी माहौल में ऐसी चीज़ें लागू करनी हों तो सहमति बननी चाहिए, लेकिन मेरी स्थिति में यह संभव नहीं था.

> मुझे इस तरह की अभिव्यक्ति पसंद नहीं है, लेकिन PHP developers को भी developer की तरह नहीं माना जाने वाला ऐसा case...

अब पीछे मुड़कर देखता हूँ तो लगता है कि मैं शायद ऐसे लोगों के बीच काम कर रहा था जिन्हें developer जैसा सम्मान नहीं मिलता था.
 
nemorize 2024-05-09

आपने उदाहरण के तौर पर Django के authentication, access control, form validation, DB migration tools और test tools का ज़िक्र किया था, ये सब PHP के Laravel में भी उपलब्ध हैं।

authentication: https://laravel.com/docs/11.x/authentication
access control: https://laravel.com/docs/11.x/authorization
form validation: https://laravel.com/docs/11.x/validation
DB migration: https://laravel.com/docs/11.x/migrations
testing: https://laravel.com/docs/11.x/testing

इसके अलावा, भले ही वे external library हों या paid library,
ऐसे टूल भी मौजूद हैं जो मौजूदा DB schema को model और migration code में export कर सकते हैं, या इसका उल्टा भी कर सकते हैं,
और CRUD UI के साथ साफ-सुथरा back office देने वाला https://nova.laravel.com/ भी मौजूद है।

Django में मौजूद लगभग सभी फीचर Laravel में भी हैं।
(असल में, क्योंकि दोनों ने ही RoR के कॉन्सेप्ट को आगे बढ़ाया है, इसलिए इनके द्वारा दिए जाने वाले फीचर अपने-आप में मिलते-जुलते होना स्वाभाविक है।)
फिर भी, Django-Python से अलग Laravel-PHP में वे अतिरिक्त फायदे भी मौजूद हैं जिनका मैंने अपनी मूल टिप्पणी में ज़िक्र किया था।

यह एक निर्विवाद तथ्य है कि PHP को वेब ऐप के लिए template language के रूप में डिज़ाइन किया गया था,
लेकिन modern PHP style को स्थापित हुए लगभग दस साल हो चुके हैं, ऐसे समय में उसे सिर्फ़ एक template language मानना शायद कुछ ज़्यादा कठोर बात होगी।
 
savvykang 2024-05-09

Nova का लिंक देने के लिए देखा, लेकिन यह भी paid license वाला है। प्रोजेक्ट ट्यूटोरियल में स्पष्ट रूप से बताया गया Django admin, जिसे तुरंत इस्तेमाल किया जा सकता है, उससे features भले मिलते-जुलते हों, लेकिन accessibility के मामले में फर्क दिखता है.

साथ ही, मेरा मानना है कि Laravel ऐसी चीज़ है जो open source contributors की बजाय Rasmus या Zend जैसी कंपनियों द्वारा, 2011 में नहीं बल्कि लगभग 2007 के आसपास, किसी अलग प्रोजेक्ट के रूप में नहीं बल्कि भाषा की आधिकारिक feature के रूप में आनी चाहिए थी। Python 3 में backward compatibility का कुछ हिस्सा छोड़ने की वजह से adoption में दिक्कतें आई थीं, लेकिन मुझे लगता है कि PHP को भी version 5 के आसपास backward compatibility की बड़े पैमाने पर सफाई कर लेनी चाहिए थी। कभी-कभी लगता है कि PHP में बदलाव हमेशा समय के रुझान से थोड़ा पीछे आते हैं.

अब व्यक्तिगत रूप से मैं वेब डेवलपमेंट में नया प्रवेश करने की स्थिति में नहीं हूँ, इसलिए PHP चुनने की नौबत नहीं आएगी।
 
okkorea 2024-05-09

आप भाषा और framework को बार-बार भ्रमित कर रहे हैं।
 
savvykang 2024-05-09

मुझे नहीं लगता कि एक ही बात कई जगहों पर टिप्पणी के रूप में लिखने की ज़रूरत है। क्या आप ध्यान आकर्षित करना चाहते हैं?
 
tested 2024-05-08

बेशक यह पहले से बेहतर हुआ है, लेकिन अब इस समय PHP इस्तेमाल करने की बजाय Node.js या Python का इस्तेमाल करना ज़्यादा बहुउपयोगी लगता है, क्योंकि इनके इस्तेमाल की जगहें ज़्यादा दिखती हैं।
 
zihado 2024-05-08

PHP का दौर आने वाला है
 
savvykang 2024-05-08

10 सालों में PHP ecosystem, deployment methods, execution model, debugging तरीकों आदि में कितनी बेहतरी आई है, इसका कोई ज़िक्र ही नहीं है। और PHP में development करना जानने वाले लोगों का बदलना सबसे ज़्यादा समय लेने वाला और मुश्किल काम है, इसलिए मुझे खास तौर पर कोई उम्मीद भी नहीं है कि यह बेहतर होगा। खासकर linked post एक PHP freelancer के marketing ब्लॉग के लिए है, इसलिए लगता है कि इसे विशेष सावधानी के साथ चुनकर ही स्वीकार करना चाहिए।
 
okkorea 2024-05-09

पिछले 10 सालों में Composer पैकेजों (Node के npm जैसी डिस्ट्रीब्यूशन) के आधार पर PHP के उपयोग आँकड़ों में PHP 5 या उससे नीचे लगभग पूरी तरह खत्म हो चुका है, और PHP इकोसिस्टम को Composer-केंद्रित हुए काफी समय हो गया है.

कुछ CMS जैसे WordPress, GnuBoard वगैरह पूरी तरह अलग-थलग हैं.

CMS को छोड़कर इकोसिस्टम की स्थिति ऊपर जैसी ही है.
 
hided62 2024-05-08

PHP इस्तेमाल करने वाले के नज़रिए से देखें, तो आज भी PHP सबसे खराब भाषा है.
क्योंकि दूसरी भाषाएँ और बेहतर हो गई हैं.
 
GN⁺ 2024-05-08
Hacker News राय

सारांश:

  • PHP पहले की तुलना में काफ़ी बेहतर हुआ है, लेकिन इसमें अब भी असंगत syntax और छिपे हुए pitfalls मौजूद हैं
  • PHP वेब प्रोग्रामिंग का सबसे शुद्ध रूप है, जहाँ framework के बिना खुलकर प्रयोग किया जा सकता है और मज़ा लिया जा सकता है
  • PHP के साथ वेब frontend, cron job, shell script, message queue, WebSocket server, client software, statistics, server automation आदि सब कुछ सीधे बनाते हुए आनंद लिया जा सकता था
  • PHP की मुख्य समस्या जोड़े गए features नहीं, बल्कि language design की बुनियादी खामियों में है (PHP: a fractal of bad design देखें)
  • commercial projects में PHP का उपयोग करते समय version management या testing की कमी, FTP के ज़रिए सीधे file edit करना, और hackers के लिए असुरक्षित WordPress plugins जैसी समस्याएँ थीं
  • PHP 5 की बड़ी समस्या feature की कमी नहीं, बल्कि fopen() में error code न मिल पाने जैसे बुनियादी मुद्दे थे
  • "अब सबसे खराब नहीं रही language" की समस्या यह है कि language बेहतर हो जाने पर भी पुराने versions को target करने वाली libraries का उपयोग करना पड़ता है
  • अच्छा होगा अगर ऐसे उदाहरण हों जो दिखाएँ कि PHP में हुए सुधार वास्तव में usability के लिहाज़ से अच्छी तरह लागू किए गए हैं
  • PHP व्यावहारिक engineers के लिए उपयुक्त है, और Laravel Octane जैसे tools के साथ high-performance applications भी बनाए जा सकते हैं
  • जिन लोगों का अतीत में PHP के साथ कठिन अनुभव रहा है, वे PHP के बेहतर हो जाने के बाद भी शायद इसे फिर से इस्तेमाल नहीं करना चाहेंगे
 
okkorea 2024-05-09

12 साल पुराना दस्तावेज़ lol
 
nalcoder0913 2024-05-08

2012 में लिखे गए दस्तावेज़ को अब भी....
क्या आप सोचते हैं कि php बिना किसी प्रगति के 2012 के उसी दौर में ज्यों-का-त्यों बना हुआ है..?

हाँ, यह तो नकारा नहीं जा सकता कि यह एक ऐसी भाषा है जिसकी शुरुआत बिना किसी ठोस आधार के हुई थी। हाहा
 
regentag 2024-05-10

यह उल्लिखित अंग्रेज़ी दस्तावेज़ के अनुवाद संस्करण का लिंक है..

PHP चाहे जितना भी खराब रहा हो, क्या ऐसा हो सकता है कि उस दौर की समस्याएँ अभी भी बनी हों।
 
tryhelloworld 2024-05-09

मेंटेन करना भी अपने-आप में समस्या है। जब इस स्तर तक डिज़ाइन ही गलत हो, तो सिर्फ version upgrade करके quality बेहतर हो गई? इसका मतलब है कि backward compatibility को बुरी तरह तोड़ा गया, और वही समस्या है। comparison operator से ही चीज़ें अजीब हैं, अब इसमें क्या किया जा सकता है।
 
nemorize 2024-05-08

ऐसा लगता है कि इसमें बस Hacker News Summary के चौथे लिंक का कोरियाई अनुवाद ही दिया गया है, हाहा।