वेब फ्रेमवर्क सरल, सुरुचिपूर्ण और प्रोग्रामिंग भाषाओं की तरह मज़ेदार क्यों नहीं हैं? [बन्द है]

Question

जब मैं किसी भी प्रोग्रामिंग लैंग्वेज के बारे में सोचता हूं - जैसे C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java, इत्यादि - मैं कमाल का हूं, मैं किसी भी एप्लिकेशन का उपयोग करके कंप्यूटर एप्लिकेशन विकसित करना पसंद करूंगा उन भाषाओं के।

लेकिन जब मैं वेब फ्रेमवर्क के बारे में सोचता हूं (मैं ज्यादातर पीएचपी करता हूं) - जैसे केक, सीआई, सिम्फनी, लारवेल, ज़ेंड, ड्रुपल, जुमला, वर्डप्रेस, रेल्स, Django, आदि - मैं भगवान की तरह हूं।

वेब फ्रेमवर्क क्यों नहीं हैं जो मुझे प्रोग्रामिंग भाषा की तरह सरल, मजेदार और शक्तिशाली निर्माण प्रदान करते हैं?

Comments

"मुझे लगता है कि मैं उन भाषाओं में से किसी का उपयोग करके एक कंप्यूटर अनुप्रयोग विकसित करना पसंद करूँगा, मुझे बहुत अच्छा लगा।" और क्या आप उन भाषाओं में से किसी में भी मास्टर हैं? क्योंकि जो कोई भी जानता है कि वे क्या कर रहे हैं, आपको बताएगा कि कोई भाषा सुरुचिपूर्ण या मज़ेदार नहीं है। वे आपके लक्ष्यों को प्राप्त करने के लिए सिर्फ उपकरण हैं, और जैसा कि उपकरण में उनकी समस्याएं और दोष हैं।

— व्यंग्यात्मक

@ 10 साल के अनुभव के साथ, मैं असहमत हूं। कुछ भाषाओं के साथ काम करने में मज़ा आता है; दूसरों को एक दर्द है। और कुछ अच्छी तरह से डिज़ाइन किए गए हैं जो सुरुचिपूर्ण हैं, साथ ही साथ। हालांकि, मैं इस बात से सहमत हूं कि इन सभी की अपनी समस्याएं हैं।

— इजाकाता

@ इज़काटा 10 साल उनमें से हर एक के साथ?

— व्यंग्यात्मक

@ समृद्ध भाषाओं के बारे में 10 साल, लेकिन सभी काफी अलग प्रकार के (सी बनाम जावास्क्रिप्ट के आदेश पर), और एक पूरे गुच्छा के लगभग 3 साल अधिक। मैंने प्रश्न में उल्लिखित लोगों में से एक तिहाई का उपयोग किया है, और बहुत अधिक उल्लेखित नहीं हैं (मेरे पसंदीदा, रेबोल सहित)। मेरे लिए, उदाहरण के लिए, जावास्क्रिप्ट और Rebol "मजेदार" भाषाएं हैं, जबकि Rebol और Lisp "सुरुचिपूर्ण" हैं (और मैंने सुना है हास्केल भी है, लेकिन मुझे यह नहीं पता है)। यदि आप एक भाषा का पर्याप्त उपयोग करते हैं, और इसकी ताकत और कमजोरियों के खिलाफ भागते हैं, तो ये "मज़ेदार" और "सुरुचिपूर्ण" राय जल्दी से अपने दम पर बनती हैं।

— इजाकाता

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

— एसके-तर्क

Answer 1

मेरे पास यह प्रश्न वर्षों से था, भले ही मैं पायथन की तरफ हूं। इस घटना के लिए मेरे पास एक भी स्पष्टीकरण नहीं है, लेकिन इस विषय पर मेरे विचार हैं:

• वेब-फ्रेमवर्क को XMLish मार्कअप लैंग्वेज - HTML, वर्तमान वेब-ट्रायड HTML-CSS-जावास्क्रिप्ट का हिस्सा क्लाइंट-सर्वर तरीके से निपटना चाहिए। इसका अर्थ तीन भाषाएं हैं, जो एक दूसरे के साथ बातचीत करती हैं, एक ब्राउज़र डोम और निष्पादन मॉडल (और सुरक्षा मॉडल)। वास्तव में, कार्यक्षमता के प्रत्येक टुकड़े (एक "मॉड्यूल") में तीनों भाषाओं में इसका कोड होना चाहिए। इसे जोड़ने के लिए, jQuery की चयनकर्ता भाषा देखभाल के लिए एक और भाषा बन रही है।

• HTML + CSS में वस्तुओं को रखने के लिए सहज और गणितीय ध्वनि मॉडल का अभाव है। यहां तक ​​कि Tcl / Tk IMHO है जो ज्यामिति प्रबंधकों को परिभाषित करने में बेहतर है। यह प्रोग्रामर को HTML रेंडरिंग को सख्त शब्दों में परिभाषित करने से रोकता है और इसके बजाय भाग्य पर भरोसा करता है: "शायद यह डिव अधिकांश समय अधिकांश ब्राउज़रों में काम करेगा"। इस ओर कुछ सकारात्मक घटनाक्रम हैं, उदाहरण के लिए, HTML5 और ट्विटर बूटस्ट्रैप।

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

• वेब ब्राउज़र में अभी भी थोड़ी असंगतताएं हैं, और यह वेब-फ्रेमवर्क में अनावश्यक जटिलता जोड़ता है

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

• वेब-ढांचा आवश्यक रूप से बहुत सी अवधारणाओं और प्रसंस्करण पाइपों को जोड़कर इन जटिलताओं से निपटता है।

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

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

मुझे लगता है, सुविधाजनक वेब-फ्रेम बनाना तभी संभव होगा जब जीयूआई मानक लागू होंगे (ऑपरेशन के विभिन्न तरीकों, जैसे मोबाइल डिवाइसेस को कवर करना) और अंतर्निहित प्रौद्योगिकियां पर्याप्त रूप से स्थिर होंगी।

वेब-फ्रेमवर्क में सरल निर्माणों की कमी होती है क्योंकि वेब-प्रौद्योगिकी डोमेन में ऐसी चीजें नहीं होती हैं। निचले स्तर के सार आवश्यक रूप से उच्च स्तर पर लीक होते हैं।

Answer 2

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

मुझे एक बार एक छोटा सा वेब ऐप बनाना था और उस समय मैंने कभी भी कोई सर्वर / क्लाइंट प्रोग्रामिंग नहीं की। मुझे यह पता लगाने में कुछ हफ्तों का समय लगा और सबसे कठिन हिस्सा क्लाइंट और सर्वर पर नज़र रखने के लिए मेरे सिर को पाने की कोशिश कर रहा था।

क्या यह कभी बदलेगा? मुझे शक है। इसके लिए वेब की वास्तुकला में मूलभूत परिवर्तन की आवश्यकता होगी।

Answer 3

सामान्यतया, कारण कई हो सकते हैं:

1. एब्सट्रैक्शन गैप फ्रेमवर्क के मामले में बड़ा है। एक आधुनिक प्रक्रियात्मक / ओओपी भाषा एक मशीन पर अमूर्तता प्रदान करती है, लेकिन कुछ मशीन निर्माणों को बनाए रखती है (जैसे कि एक चर को कुछ डेटा प्रदान करना / कुछ डेटा को मेमोरी यूनिट में लिखना, या एक प्रक्रिया को कॉल करना आदि); अंतर इतना बड़ा नहीं है, जबकि एक फ्रेमवर्क एक वेब एप्लिकेशन विकसित करने के लिए अमूर्तता प्रदान करने की कोशिश करता है जो बहुत अधिक अवधारणाओं के साथ काम करता है।
2. फ्रेमवर्क प्रोग्रामर के दृष्टिकोण से अधिक जटिल हो सकता है; यह पहले बिंदु के परिणाम की तरह है। एक प्रोग्रामिंग भाषा बल्कि सरल है, इसमें सरल निर्माण हैं (यदि, के लिए, चर, प्रक्रिया आदि)। इसके अलावा मानक पुस्तकालय सरल चीजें जैसे IO को लिखना, या संग्रह का उपयोग करने का सार करता है। मानक पुस्तकालय यह बहुत अधिक रूपांतरित है, जिसमें मॉड्यूल पर दूसरे के साथ कुछ या कोई संबंध नहीं है; आपको संग्रह या इसके विपरीत का उपयोग करने के लिए IO को जानने की आवश्यकता नहीं है। यह ध्यान दिया जाना चाहिए कि यदि मानक पुस्तकालय के कुछ हिस्से बल्कि जटिल हैं, तो उन्हें एक मिनी-फ्रेमवर्क (जैसे जावा कलेक्शंस फ्रेमवर्क या एक्ज़ीक्यूटर्स फ्रेमवर्क) में रखा जाता है। फ्रेमवर्क के मामले में आपको पूरे प्रवाह को जानने की आवश्यकता है, यह पूरी ताकत पर फ्रेमवर्क का उपयोग करने के लिए सभी भागों में है। इसके अलावा, आ फ्रेमवर्क पहले से ही निर्मित अनुप्रयोग है;
3. इतने सारे संसाधन एक फ्रेमवर्क में नहीं रखे जाते, जितने प्रोग्रामिंग भाषा में। मेरा मानना ​​है कि इसके लिए किसी व्याख्या की जरूरत नहीं है।

Answer 4

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

Comments

मैं +1 दे रहा हूं क्योंकि पोस्ट के रूखे स्वभाव के बावजूद, यह सही है कि फ्रेमवर्क आवश्यक रूप से ट्यूरिंग-पूर्ण नहीं हैं। यह पूरी तरह से सामान्य-प्रयोजन की भाषा के ड्रा में से एक है, अगर आप जानते हैं कि कुछ भी करने की क्षमता है।

— इजाकाता