"आपके जावा टॉक में कितने दर्शक आएंगे?" यह इस बात पर निर्भर करता है कि वेंकट उसी समय बगल के हॉल में प्रदर्शन कर रहा है या नहीं। ”
यह सत्य की एक उचित राशि के साथ एक मजाक है: जावा दुनिया में,
वेंकट सुब्रमण्यम सबसे प्रसिद्ध वक्ताओं में से एक है, जो वास्तव में सम्मेलनों में अन्य हॉल से दर्शकों को खींचने में सक्षम है। वह लगातार ग्रह के चारों ओर घूम रहा है और हाल ही में 50 अलग-अलग जावा उपयोगकर्ता समूहों से पहले एक वर्ष में अपने 50 वें जन्मदिन के बोल द्वारा एक प्रभावशाली रिकॉर्ड स्थापित किया है।
जब आपका जावा करियर "कार्यालय में नहीं बैठा", लेकिन "लगातार आगे बढ़ रहा है" तो ऐसा क्या है? और वेंकट वर्तमान जावा मुद्दों के बारे में क्या सोचते हैं? अक्टूबर में, वह सेंट पीटर्सबर्ग जाएगा, और इस की प्रत्याशा में, हमने (
फ़िलेनिअम ,
ऑलेग्चिर ) ने विस्तार से उसका साक्षात्कार किया, जहां हमने "विमान पर जीवन" और शुरुआत बोलने वालों के लिए युक्तियां शुरू
कीं , और फिर प्रौद्योगिकी पर चले गए।
चूंकि वेंकट विस्तार से जवाब देता है, इसलिए पाठ लंबा है। यदि आप चाहें, तो आप तुरंत दूसरे भाग में जा सकते हैं:
जीवन के लिए
- चलो अपने दौरे से शुरू करते हैं, जिसके दौरान आपने 50 जावा उपयोगकर्ता समूहों का दौरा किया, शायद ही किसी ने इससे पहले किया हो। आपके इंप्रेशन क्या थे?- मेरे लिए सबसे दिलचस्प बात यह थी कि दुनिया के विभिन्न हिस्सों में विभिन्न संस्कृतियों में, जो लोग विभिन्न भाषाओं को बोलते हैं, इन सभी मतभेदों के बावजूद, एक ही जोड़ने वाले धागे के रूप में प्रोग्रामिंग द्वारा एकजुट होते हैं। जब हम प्रोग्रामिंग के बारे में बात करना शुरू करते हैं, तो यह पता चलता है कि हर दिन हमारे सामने आने वाली समस्याएं समान हैं। यह मेरे लिए एक महान खोज थी - आप दुनिया के किसी भी हवाई अड्डे पर एक प्रोग्रामर से मिल सकते हैं, और आप निश्चित रूप से बातचीत के लिए सामान्य विषय पाएंगे। मैं उन मामलों की अंतहीन सूची बना सकता हूं जहां मैं पृथ्वी के दूसरी तरफ जावा के बारे में बात करने में शामिल था।
इसलिए, इन समूहों के साथ अनुभव मेरे लिए बहुत उपयोगी था। उपयोगकर्ता समूह को प्रबंधित करना बहुत मुश्किल है ... मैं "काम" नहीं कहना चाहता क्योंकि यह काम नहीं है, लेकिन आपको बहुत प्रयास करना होगा। मेरा उन सभी नेताओं के लिए बहुत सम्मान है जो हर महीने इन घटनाओं को बार-बार इकट्ठा करते हैं। अलग-अलग समूहों में अलग-अलग गतिशीलता होती है - कुछ में 20 या 30 लोग बैठकें करते हैं, अन्य 200 या 300। फिर भी, संख्या वास्तव में मायने नहीं रखती है, क्योंकि मुख्य बात डेवलपर्स की इन बैठकों में आने का जुनून है, उनकी रुचि प्रौद्योगिकी और सीखने की उनकी इच्छा। इसलिए मैं बहुत भाग्यशाली था कि मुझे इन समूहों के साथ मिलने का अवसर मिला, और मैं इसके लिए बहुत आभारी हूं।
- और आपके द्वारा उल्लेखित समानता के साथ, क्या दुनिया के विभिन्न हिस्सों में उपयोगकर्ता समूहों में कोई ध्यान देने योग्य स्थानीय अंतर हैं?- ये अंतर आश्चर्यजनक रूप से कम हैं। मैंने देखा कि कुछ क्षेत्रों में हैवीवेट फ्रेमवर्क को अधिक तरजीह दी जाती है, और अन्य में अधिक हल्के समाधानों को। लेकिन, एक नियम के रूप में, ये सभी विशेषताएं सतही हैं, और गहरे बैठे प्रश्न और समस्याएं, इसके विपरीत, सार्वभौमिक हैं। मैं ईमानदारी से आपको यह बताना चाहूंगा कि मानचित्र पर कुछ बिंदु पर लोग हमारी तुलना में पूरी तरह से अलग चीजें करते हैं, और वहां सब कुछ दिलचस्प और अप्रत्याशित है, लेकिन मैं ऐसा नहीं कह सकता।
हम सभी जटिलता के लिए प्रयास करते हैं, यह हमें परेशान करता है, और जब यह सूख जाता है, तो हम इसे लड़ना शुरू करते हैं। यह लगभग हर जगह एक सामान्य प्रवृत्ति है। एक और महत्वपूर्ण समस्या जो किसी ने नहीं छोड़ी है वह है व्यापार की सख्त आवश्यकताएं और गुणवत्ता पर काम करने के लिए समय की कमी। मैं दुनिया में कहीं भी लोगों के लिए कुछ उदाहरण के बारे में बात कर सकता हूं, और मेरी कहानी के बाद मुझसे पूछा जाएगा: "क्या आप हमारी कंपनी में काम करते हैं?" हमारी समस्याएं इतनी गहरी और सार्वभौमिक हैं कि, जाहिर है, वे पूरी दुनिया के लिए आम हैं। कौन सा अनजाने में हमें हमारे सामान्य मानव सार के बारे में, मनोविज्ञान और दर्शन के बारे में सोचता है, जिसे हम अंततः पालन करते हैं। कोई फर्क नहीं पड़ता कि हम खुद को जीक्स के रूप में प्रौद्योगिकी के रूप में देखते हैं, हमें सॉफ्टवेयर के विकास में मानवीय पहलू के बारे में नहीं भूलना चाहिए। जाहिर है, वह एक एकजुट और सार्वभौमिक बल है।
- मैं एक "शिविर" जीवन शैली के बारे में पूछना चाहूंगा। जब आप कार्यालय में बैठते हैं, तो यह स्पष्ट नहीं हो सकता है कि आप अपने जैसा जीवन चाहते हैं। उदाहरण के लिए, कई लोगों के लिए, जेटलैग एक समस्या है, और इस वजह से, लगातार उड़ानें एक बुरे सपने की तरह लग सकती हैं। लेकिन शायद अभ्यास के साथ, आप इस के लिए अनुकूल हैं?- अपने प्रश्न का उत्तर देने के लिए, आइए निरंतर एकीकरण को याद करें। यदि कोई टीम महीने में एक बार एकीकरण करती है, तो आप सुझाव देते हैं कि वे हर समय ऐसा करते हैं, वे आपको पागल समझेंगे। इसमें, यात्रा संबंध निरंतर एकीकरण और निरंतर वितरण से मिलते जुलते हैं: यदि आप उनके साथ बहुत अधिक व्यवहार करते हैं, तो उनके प्रति आपका दृष्टिकोण बदल जाता है।
मुझे गलत मत समझो, मुझे अपने जीवन के तरीके पर गर्व नहीं है, मेरी राय में, यह उस तरह से रहने लायक नहीं है। मैं हमेशा कहता हूं कि यात्रा में मैं कम से कम यात्रा को खुद पसंद करता हूं। एक विमान पर बैठना थका देने वाला होता है, शरीर खराब हो जाता है, और उम्र के साथ, ये समस्याएं कहीं भी नहीं जाती हैं। लेकिन जब मैं अपने गंतव्य पर पहुंचता हूं, जब मैं अन्य डेवलपर्स के साथ मिलता हूं, तो मैं प्रौद्योगिकी के लिए उनके जुनून, उनके उत्साह को देखता हूं, मुझे इस जुनून को साझा करने, कुछ नया सीखने और इसे सीखने में मदद करने का अवसर मिलता है, सभी कठिनाइयां ब्याज के साथ भुगतान करती हैं।
अगर हम समय क्षेत्र के बदलाव के बारे में बात करते हैं, तो यह मुझे बिल्कुल परेशान नहीं करता है। निरंतर उड़ानों के कारण, एक निश्चित अर्थ में मेरे पास निरंतर, "घर" समय नहीं है। मेरे पास एक नियम है: मैं हमेशा एक ही स्थानीय समय पर जागता हूं, रात में लगभग 3.30 बजे, और शरीर बहुत जल्दी एक निश्चित लय में प्रवेश करता है। और, ज़ाहिर है, कॉफी हमेशा बहुत स्वागत योग्य है।
- बहुत से लोग दुनिया को देखना पसंद करेंगे, लेकिन वे आमतौर पर पर्यटन यात्राओं पर जाते हैं, न कि व्यापारिक यात्राओं पर। क्या आप शहरों को देखने में सक्षम हैं, या केवल सम्मेलन कक्षों में समय की कमी के कारण?- हां, आंशिक रूप से समय के साथ समस्या है। लेकिन, इसके अलावा, लगातार उड़ानों के कारण, मेरे पास कुछ सिद्धांत हैं जिनका मैं पालन करता हूं। अगर यात्रा काम से जुड़ी हो, तो मैं काम के अलावा कुछ नहीं करता। मैं डेवलपर्स के साथ अधिक से अधिक समय बिताने की कोशिश करता हूं। जब मेरे पास एक मुफ्त शनिवार या रविवार होता है, उदाहरण के लिए, यूरोप में, मैं आमतौर पर इसे एक उपयोगकर्ता समूह में खर्च करता हूं। यह मुझे डेवलपर्स के साथ संवाद करने में बहुत खुशी देता है, इसलिए मेरी व्यापारिक यात्राओं पर मैं लगभग कभी भी रुचि के स्थानों पर नहीं जाता हूं।
लेकिन हर साल गर्मियों में चार या छह सप्ताह के लिए मैं अपने परिवार के साथ यात्रा करता हूं, और हम घूमने जाते हैं। यह संयुक्त आराम के लिए हमारा समय है, और शेष महीनों में मैं काम पर ध्यान केंद्रित करता हूं।
इसके अलावा, मेरा दृष्टिकोण मुझे विभिन्न सामुदायिक घटनाओं पर अधिकतम ध्यान देने की अनुमति देता है, जो मुझे बहुत खुशी भी देता है। यह बहुत समय की खपत करता है और एक तरह का समझौता है, लेकिन यह मुझे सूट करता है। जीवन कभी-कभी बहुत तनावपूर्ण होता है, और मुझे कभी-कभी विचलित होने के अवसर के बारे में खुशी होती है और उन डेवलपर्स को सुनता है जिनके पास सम्मेलन या प्रशिक्षण पाठ्यक्रम में भाग लेने का अवसर नहीं हो सकता है। इसके अलावा, मेरा मानना है कि यह मेरा पेशेवर कर्तव्य भी है, इस कारण से कि यह मेरी युवावस्था में मुझे प्रेरित करता था। मैंने उपयोगकर्ता समूहों का दौरा किया, प्रदर्शनों की बात सुनी और अपने समय में भी खुद को करने का सपना देखा। यदि मैं, बदले में, कम से कम एक व्यक्ति को उसी तरह से प्रेरित करने का प्रबंधन करता हूं, तो यह समय अच्छी तरह से व्यतीत होगा।
- अंतिम यात्रा प्रश्न। फिल्म "अप इन द एयर" में, जॉर्ज क्लूनी का चरित्र, जो लगातार शहरों के बीच उड़ान भर रहा है, यात्रा दक्षता में सुधार के लिए कई तरकीबें जानता है: लाइन में कैसे खड़ा होना है, सामान कैसे पैक करना है, इत्यादि। शायद आपके पास भी कुछ गैर-स्पष्ट ज्ञान है जिसे आप साझा करना चाहेंगे?“मुझे इसे स्वीकार करने में शर्म आती है, लेकिन मैं कभी-कभी FedEx पर शहरों के बीच कपड़े भेजती हूं, क्योंकि मेरे पास घर उड़ने और अगले सप्ताह के लिए कपड़े लेने का समय नहीं है। अक्सर, जब मैं होटल पहुंचता हूं, तो मेरे कपड़े पहले से ही मौजूद होते हैं, और जब मैं निकल जाता हूं, तो मैं उन्हें घर भेज देता हूं। सौभाग्य से, यह बहुत बार नहीं होता है, शायद साल में तीन या चार बार, जब मैं लगातार तीन सप्ताह तक अपने रास्ते पर होता हूं। एक अजीब क्षण था जब मेरी पत्नी को मुझे बैग सौंपने के लिए हवाई अड्डे जाना था, क्योंकि मेरे पास उड़ानों के बीच केवल आधे घंटे का समय था। लेकिन समय के साथ, आप वास्तव में कुछ चीजों को अधिक कुशलता से करना सीख जाते हैं। कभी-कभी यह मुझे आश्चर्यचकित करता है जब लोग कहते हैं कि "मुझे पैक करने की आवश्यकता है" क्योंकि मेरी चीजें हर समय एकत्र की जाती हैं।
दक्षता की बात करें तो मुझे कम से कम एक फायदा है: मैं बहुत ही एकल व्यक्ति हूं। हम फेसबुक, ट्विटर और विभिन्न दूतों की दुनिया में रहते हैं, वे लगातार हमें विचलित करते हैं। मैंने इस प्रभाव को कम करने के लिए कड़ी मेहनत की, क्योंकि मिनट घंटों में बदल जाते हैं, घंटे दिन में बदल जाते हैं, दिन हफ्तों में बदल जाते हैं, और जल्द ही या बाद में आपको एहसास होता है कि आप जो चाहते थे वह हासिल नहीं कर पाए। आमतौर पर मेरे पास एक पत्रिका होती है जिसमें मैं उन चीजों को लिखता हूं जो प्रत्येक यात्रा के लिए आवश्यक होती हैं। इस प्रकार, मेरे पास हर दिन (उदाहरण के लिए, 7 नवंबर या 8 अक्टूबर) के लिए एक कार्यक्रम है, और मेरा फोन मुझे उसी दिन प्रत्येक कार्य की याद दिलाता है। आठ घंटे की उड़ान में, मैं पुस्तक के अधिकांश एक अध्याय को लिख सकता हूं, या पाठ्यक्रम के लिए एक उदाहरण तैयार कर सकता हूं। इसलिए, मेरे लिए उड़ानें बेहद प्रभावी समय हैं। मुझे उड़ान के दौरान अतिरिक्त मनोरंजन की आवश्यकता नहीं है - कोड डिबगिंग से संबंधित पर्याप्त मनोरंजन काफी पर्याप्त है। तो एक पेशेवर यात्री (यदि ऐसा शब्द आम तौर पर लागू होता है) एक पर्यटक की तुलना में उड़ान में काफी समय बिताता है।
- शायद, आपकी प्रसिद्धि के कारण, आपको सामान्य डेवलपर्स की तुलना में बहुत अधिक पत्र मिलते हैं। वे आपको कितना लिखते हैं और मेल लेने में कितना समय देते हैं?- यह जोड़ने योग्य है कि मैं विश्वविद्यालय में पढ़ाता हूं और छात्रों से कई पत्र प्राप्त करता हूं। आमतौर पर मुझे एक दिन में 20 या 30 पत्र मिलते हैं। लगभग एक साल पहले मैंने अपने एक सिद्धांत के बारे में एक ब्लॉग पर
लिखा था : "अब जवाब दो या कहो जब तुम जवाब दो।"
मैं वास्तव में अपने समय को महत्व देता हूं, जिसका अर्थ है कि मैं अन्य लोगों के समय को महत्व देता हूं। मेरी राय में, किसी अन्य व्यक्ति का सम्मान सर की अपील में नहीं है, बल्कि एक-दूसरे के समय की सराहना करने में है। इसलिए, यदि कोई पत्र मेरे पास आता है, तो मैं हमेशा 24 घंटे के भीतर जवाब देता हूं। लेकिन ऐसे समय होते हैं जब यह एक पूर्ण उत्तर देने के लिए काम नहीं करता है - उदाहरण के लिए, यदि सम्मेलन का आयोजक एक एनोटेशन भेजने के लिए कहता है या यदि उद्योग में कोई सहकर्मी एक निश्चित समस्या को हल करने के बारे में एक प्रश्न पूछता है, तो कुछ कोड को वापस करने के लिए कहता है, या एक निश्चित विधि का उपयोग करने के बारे में पूछता है। कभी-कभी उत्तर में दस मिनट लग सकते हैं, और कभी-कभी दो घंटे, लेकिन दस मिनट भी हमेशा खर्च नहीं किए जा सकते हैं। यह थोड़ा अजीब लग सकता है, लेकिन मैं अभी भी ऐसे मामलों में 24 घंटे के भीतर जवाब देता हूं और लिखता हूं: मुझे आपका पत्र मिला है, मैं इस समस्या पर काम करूंगा, 2 सितंबर को लिखूंगा और आपको तीसरा लिखूंगा। उसी समय, मेरे कैलेंडर को उस दिन के अनुरूप प्रविष्टि के साथ अपडेट किया जाता है जब मेरे पास उड़ान में या दोपहर में समय होता है।
इस दृष्टिकोण के लिए धन्यवाद, मेरा इनबॉक्स हमेशा खाली होता है, मैं इसे हर रात सोने से पहले साफ करता हूं। इसलिए मैं पत्रों का जवाब देने में बेहद अनुशासित हूं। लोग अक्सर आश्चर्यचकित होते हैं कि मैं उनके पत्रों पर इतनी जल्दी प्रतिक्रिया देता हूं, लेकिन मैं, इसके विपरीत, यह नहीं समझता कि अन्यथा कैसे। मैं लोगों के रास्ते में नहीं खड़ा होना चाहता, ताकि उन्हें विकसित होने से रोका जा सके। इसके अलावा, मैं नहीं कहना महत्वपूर्ण मानता हूं। मुझे यह दोहराना अच्छा लगता है कि जितना अधिक आप हाँ कहेंगे, उतना ही बुरा होगा जो आप करते हैं। एक निश्चित समय पर, आपको यह महसूस करना होगा कि हम दुनिया में सब कुछ हासिल नहीं कर सकते। इसलिए, कभी-कभी मैं जवाब देता हूं कि दुर्भाग्य से, मैं मदद नहीं कर सकता। बदले में, मैं तुरंत नहीं कहा जाना पसंद करता हूं, और रबर नहीं खींचता और कहा कि बाद में नहीं। मेरी राय में, यह व्यक्ति के सम्मान की बात भी करता है और बेवजह अपना समय बर्बाद करने के लिए। आपको मदद करने की ज़रूरत नहीं है, लेकिन कम से कम परेशान न करें। इसलिए, यह नहीं कहना महत्वपूर्ण है। यह है कि जीवन कैसे व्यवस्थित किया जाता है, यह दिखावा करने की कोशिश न करें कि आप दुनिया में सब कुछ कर सकते हैं। मेरे लिए, जल्दी और ईमानदारी से जवाब देने की क्षमता व्यावसायिकता का संकेत है।
- आप बहुत अनुभवी वक्ता हैं। सम्मेलन आयोजकों के रूप में, हम ऐसे लोगों से मिलते हैं जिनके पास सार्वजनिक बोलने का अनुभव नहीं है या जिनके पास बहुत कम हैं। शायद आपके पास उनके लिए सिफारिशें हैं? आपके पास ट्विटर पर एक दिलचस्प टिप थी "हॉल का दौरा करने के लिए जिसमें रिपोर्ट अग्रिम में आयोजित की जाएगी" - क्या कोई और है?- मेरी पहली रिपोर्ट उपयोगकर्ता समूहों में थी, यही वजह है कि मैं हर साल उन में 15 रिपोर्ट बनाना जारी रखता हूं। और मैं सलाह देता हूं कि अन्य लोग एक ही चीज़ से शुरू करें: आपके क्षेत्र में एक उपयोगकर्ता समूह के साथ, फिर एक पड़ोसी में, और इसी तरह।
कई कारणों से, इन रिपोर्टों में एक बड़े सम्मेलन की तुलना में कम जोखिम होता है: एक दोस्ताना माहौल होता है, लोग ज्ञान साझा करने के लिए वहां आते हैं, आपकी रिपोर्टों के बाद आपके लिए प्रतिक्रिया प्राप्त करना आसान होगा। आप बहुत अच्छी तरह से यह कहकर प्रस्तुति शुरू कर सकते हैं कि आपको इस मामले में बहुत कम अनुभव है और दर्शकों की राय जानना चाहते हैं। इस साल मेरे पास एक नई रिपोर्ट थी, जिसकी तैयारी के दौरान मैंने बहुत अनुभव किया। मैंने ट्विटर पर इसके बारे में लिखा है: ऐसा लगता है कि सब कुछ दो मिनट में कहा जा सकता है, लेकिन वास्तव में सामग्री को एक घंटे और एक आधे में नहीं रखा जा सकता है। और मुझे बहुत खुशी है कि पहली बार मैंने यह रिपोर्ट एक उपयोगकर्ता समूह में बनाई, क्योंकि इससे मुझे सम्मेलन के लिए बेहतर तैयारी करने का अवसर मिला।
उपयोगकर्ता समूहों में या कंपनी में जहां आप काम करते हैं, आपके पास प्रस्तुतियों का अभ्यास करने का एक शानदार अवसर है। सबसे पहले, आपको सहकर्मियों से आलोचना प्राप्त होगी, जो आपको रिपोर्ट में सुधार करने की अनुमति देगा। दूसरी बात, भले ही वे आपसे सीधे कुछ भी न कहें, फिर भी जब आप बात करना शुरू करेंगे तो आप खुद भी बहुत कुछ समझ जाएंगे। मेरा मानना है कि तीसरी बार से रिपोर्ट को वास्तव में सुधारना संभव है। पहली बार जब आप केवल सभी विचारों को एक साथ लाने की कोशिश कर रहे हैं। और यहाँ क्या दिलचस्प है: अकेले अभ्यास करने से यहाँ मदद नहीं मिलेगी, समस्याओं के बारे में जागरूकता केवल अन्य लोगों से बात करते समय आती है। तीसरी बार, आपके कथन की तार्किक श्रृंखला आपके लिए स्पष्ट हो जाती है, यह पूरी हो जाती है। यह हमेशा ध्यान देने योग्य नहीं है, लेकिन मैं कभी-कभी तीसरी बार अपने भाषण के दौरान रुकता हूं - इस समय मुझे एहसास होता है कि यह मैं क्या था जो रिपोर्ट में यह कहना चाह रहा था कि सच्चाई का एक प्रकार का क्षण आता है। इसलिए, अभ्यास बहुत महत्वपूर्ण है, लेकिन अकेले नहीं, बल्कि लोगों के साथ। यह युवा डेवलपर को आवश्यक आत्मविश्वास दे सकता है।
सच है, कुछ सम्मेलनों में अपनी पहली रिपोर्ट बनाते हैं। कभी-कभी किसी व्यक्ति के लिए सार्वजनिक रूप से बोलना आसान होता है, और उन्हें समझना आसान होता है - यह बहुत सारी नसों को ले जाता है। दो या तीन साल पहले, मैंने एक सम्मेलन में बात की थी। एक बहुत ही इच्छुक व्यक्ति मेरे पास आया और उसने कहा कि, जाहिर है, मैं बहुत चिंतित था, जिस पर मैंने जवाब दिया कि यह वास्तव में ऐसा था। उन्होंने पूछा, "क्या यह आपकी पहली रिपोर्ट है?", और मैंने जवाब दिया: "नहीं, शायद दस हजार, इसलिए मैं चिंतित हूं।" दर्शकों के सामने प्रत्येक प्रदर्शन के लिए बहुत अधिक भावनात्मक तनाव की आवश्यकता होती है, भले ही आपके पास बहुत अनुभव हो, केवल इसलिए कि आप इस बात की परवाह करते हैं कि रिपोर्ट कैसे जाती है। यदि आप उपयोगकर्ता समूहों या अपनी कंपनी में कुछ परीक्षण रिपोर्ट के साथ इस तनाव को कम करते हैं तो आप एक अच्छा काम करेंगे। यह अनुभवी सहित सभी वक्ताओं पर लागू होता है।
- लेकिन क्या सार्वजनिक बोलने में कुछ ऐसा है, जो इसके विपरीत होना चाहिए?"मैंने अपने जीवन में कई गलतियाँ कीं, जिसने मुझे सिखाया कि लोग अनुभव से सर्वश्रेष्ठ सीखते हैं।" जब आप एक दर्शक से बात करते हैं, तो कुछ बातों का ध्यान रखना चाहिए। सबसे पहले, आपको आत्मविश्वास बनाए रखने की आवश्यकता है: आपने विषय पर बहुत काम किया है, और आप इसके बारे में बहुत कुछ जानते हैं। दूसरे, याद रखें: यह सब कुछ जानना असंभव है, और किसी चीज की अज्ञानता आपकी गलती नहीं है। इसका सिर्फ यह मतलब है कि आपके पास इस पर ध्यान देने का अवसर नहीं था, और इसमें कुछ भी गलत नहीं है। यह ईमानदारी से अपने आप को स्वीकार करने के लिए अत्यंत महत्वपूर्ण है। आप इस तरह के सम्मेलन में इस प्रश्न का उत्तर दे सकते हैं: क्षमा करें, मैं आपको कुछ भी नहीं बता सकता, मुझे इस समस्या का अध्ययन करने का अवसर नहीं मिला।
एक और महत्वपूर्ण बिंदु यह है कि श्रोताओं को तीन प्रकारों में विभाजित किया जा सकता है। ऐसे लोग हैं जो आपसे कुछ नया सीखना चाहते हैं। दूसरे लोग खुद को थोड़ा अधिक सावधान रखते हैं, वे आपकी बात सुनेंगे, लेकिन वे आपकी हर बात को समझने के लिए तैयार नहीं होंगे। अंत में, लोगों का एक तीसरा समूह है, सौभाग्य से, बल्कि छोटा: वे जो शत्रुतापूर्ण हैं और हर समय आपको पकड़ने की कोशिश कर रहे हैं। जल्दी या बाद में, आपकी रिपोर्ट में निश्चित रूप से एक डेवलपर होगा जो आपको हर समय बाधित करेगा और रिपोर्ट की प्रगति को बाधित करेगा। ऐसे मामलों में, शांत रहना बहुत महत्वपूर्ण है, उसे बात करने दें और चर्चा को उस दिशा में लौटाएं जिसकी आपको ज़रूरत है - लेकिन, मुझे मानना होगा, मैं भी एक व्यक्ति हूं, और मैं हमेशा ऐसा करने में सफल नहीं होता। उदाहरण के लिए, आप कह सकते हैं: मैं समझता हूं कि यह आपके लिए महत्वपूर्ण है, आइए रिपोर्ट के बाद इस पर चर्चा करें, यह विषय यहां कई लोगों के लिए महत्वपूर्ण है। सच है, बहुत बार आप दर्शकों में सहयोगी होते हैं, और जब कोई व्यक्ति वास्तव में अपने भाषण के पाठ्यक्रम का उल्लंघन करता है, तो उसे शांत करने के लिए कहा जाता है। यह सब मैं इस तथ्य से कहता हूं कि ऐसी स्थितियों में बहुत संघर्ष नहीं करना महत्वपूर्ण है, भले ही हमारी प्रकृति इसका विरोध कर सकती है। एक युवा वक्ता के रूप में, मैंने अक्सर पूरी ताकत से इस तरह के टकरावों में प्रवेश किया, और इससे कभी किसी का भला नहीं हुआ। भावनात्मक परिपक्वता दिखाने के लिए आवश्यक है और इस तरह की झड़प में प्रवेश करते हुए, अपने बारे में किसी को कुछ भी साबित करने की कोशिश न करें। इसके बजाय, ऐसे मामलों में, विषय को वापस लिया जाना चाहिए जो दर्शकों के लिए दिलचस्प है।
मैं प्रदर्शन के दौरान कुछ नकारात्मक आदतों के बारे में बात करना चाहूंगा, जो, मेरी राय में, डेवलपर्स के पास है। शुरुआत के लिए, लोगों को अपनी आंखों में देखना चाहिए। मैं समझता हूं कि यह बहुत कठिन है और इसके लिए बहुत भावनात्मक प्रयास की आवश्यकता होती है, लेकिन आपको इसका अभ्यास करने की आवश्यकता है। स्क्रीन पर अक्सर दर्शक अपनी निगरानी में, या उससे भी बुरी स्थिति में, अपनी पीठ के बल खड़े होते हैं। आपको हमेशा दर्शकों का सामना करने की आवश्यकता होती है और आपको हमेशा उन्हें देखना चाहिए। इसके अलावा, आत्मविश्वास बनाए रखना चाहिए। आप प्रोग्रामर के दर्शकों से बात करते हैं, और आप शर्त लगा सकते हैं कि उनमें से किसी के पास कोड नहीं है जो पहली बार काम करता है। यदि प्रस्तुति के दौरान आपका प्रदर्शन काम नहीं आया, तो इसमें कुछ गलत नहीं है। सभी उपस्थित लोगों को सबसे अधिक संभावना होगी: "धिक्कार है, मेरे साथ सब कुछ वैसा ही है।" वर्षों से, मैंने ऐसी स्थितियों में डिबगिंग की मदद के लिए दर्शकों की ओर रुख करना सीखा है। आमतौर पर, ऐसी स्थिति में बोलने वाले अपनी सांस के तहत कुछ गुनगुनाना शुरू करते हैं और अपने दम पर सभी कठिनाइयों को हल करने का प्रयास करते हैं। इसके बजाय, आपको दर्शकों से पूछना चाहिए - दोस्तों, क्या आप मुझे बता सकते हैं कि मैं कहां गूंगा हूं? , . , . . , : , , , . , .
— Java- , Java «Hello world». «public static void main» , , .
: Java- , , , . , . - - Java?— , . , , Java — , 2000-. , , , .
, , , , , . , , 70 try-catch . , , , .
— . , , , . , , . , . , .
Java 12, 13 14 : , , Java , , . , , Java , . , , . , , Java . , , , Java . , , , , , Java .
. Joker «Don't walk away from complexity, run» . , Joker , , .
- "कम बमबारी वाले जावा" के संदर्भ में, आपको कोटलिन के बारे में पूछना असंभव नहीं है, जिसे अक्सर कहा जाता है।"हाँ, यह सच है।" और मामला केवल कम दिखावा में नहीं है। मेरे लिए, जीवन की सबसे रोमांचक चीजों में से एक नई भाषाओं और उनकी क्षमताओं को जानना है। कोटलिन में एक संभावना एक वस्तु के संदर्भ में लंबोदर को चलाने की है, भले ही वह वर्ग का हिस्सा न हो। जब मुझे पता चला तो मुझे बहुत दिलचस्पी हुई, क्योंकि जावास्क्रिप्ट में भी यही संभावना है। वहां आप कॉल में एक संदर्भ ऑब्जेक्ट (जिसे कोटलिन कॉल रिसीवर कहते हैं) पास कर सकते हैं, और फिर इस मनमाने वैश्विक फ़ंक्शन को निष्पादित कर सकते हैं जैसे कि यह किसी वस्तु का फ़ंक्शन था। तथ्य यह है कि यह सुविधा जावास्क्रिप्ट में है, आश्चर्य की बात नहीं है क्योंकि यह भाषा गतिशील है। लेकिन कोटलिन एक स्थिर भाषा है, और यह ऐसा ही करता है, जबकि प्रकार की सुरक्षा का सम्मान करता है। निस्संदेह, दिखावा की कमी, भाषा का एक बड़ा फायदा है, जैसा कि यह तथ्य है कि यह कोड का एक महत्वपूर्ण हिस्सा स्वचालित रूप से उत्पन्न करता है, जिससे हम एक ही टेम्पलेट को बार-बार नहीं लिख सकते हैं। लेकिन लाभ वहाँ खत्म नहीं होते हैं, क्योंकि यह सुविधा आपको आंतरिक डीएसएल बनाने की अनुमति देती है।
विज्ञान और गणित ने मुझे प्रोग्रामिंग के लिए प्रेरित किया, लेकिन 30 साल बाद भी मैं इस तथ्य के कारण एक प्रोग्रामर बना रहा कि यह कला है। हमारा क्षेत्र विज्ञान और कला को जोड़ता है, इसके आसपास कोई नहीं है। केवल सिस्टम के काम करने की क्षमता सीमित नहीं है, यहां आप कविता लिखने के साथ एक सादृश्य आकर्षित कर सकते हैं: दो लोगों को प्यार के बारे में लिखने के लिए कहें, और प्रत्येक अपने तरीके से लिखेंगे। किसी भी कार्य के लिए कोड कई अलग-अलग तरीकों से लिखा जा सकता है। यह मुझे कोटलिन और कई अन्य भाषाओं की ओर आकर्षित करता है: इन विचारों में से कुछ को व्यक्त करने की क्षमता, कोड को लचीलापन और लपट देता है। आप भाषा के वाक्य-विन्यास के बारे में बहुत कम सोच सकते हैं और उस विचार के बारे में जिसे आप बताना चाहते हैं।
- कोड की गुणवत्ता आपके लिए बहुत महत्व रखती है। यह सभी के लिए महत्वपूर्ण लगता है, और ऐसा लगता है कि हर कोई बेहतर लिखना चाहता है, लेकिन यह ज्ञात है कि मौजूदा कोड के एक महत्वपूर्ण हिस्से में समस्याएं हैं। इसलिए, सवाल यह है: ताकि आपके सहकर्मी आपके कोड के लिए आपसे घृणा न करें, आपको बस आत्म-अनुशासन की आवश्यकता है, क्या आप कोई विशिष्ट सिफारिशें दे सकते हैं?"मुझे विश्वास है कि पठनीय कोड लिखने का एकमात्र तरीका इसे पढ़ना है।" जब वे मुझे बताते हैं कि कोड पठनीय है, तो मैं पूछता हूं - इसे कौन पढ़ता है? यदि लेखक स्वयं इसे लिखने के तुरंत बाद पढ़ता है, तो यह गणना नहीं करता है। इसलिए, मैं कोड समीक्षा में एक मजबूत आस्तिक हूं। मैं स्पष्ट करना चाहता हूं: मैं एक टीम को बड़ी स्क्रीन के साथ एक कमरे में लाने का विरोध कर रहा हूं, इस पर कोड दिखा रहा हूं और इसकी आलोचना कर रहा हूं। यह अनिवार्य रूप से शिकायतों की ओर जाता है, इस तरह के सार्वजनिक ओखनाई कोई भी अच्छा नहीं है।
हमें ईमानदारी से मानना चाहिए: हम सभी बुरे कोड लिखते हैं। मुझे यह स्वीकार करते हुए गर्व हो रहा है: मेरा कोड बेकार है, मुझे नहीं पता कि मुझे अच्छा कोड कैसे लिखना है। यदि आप पूछते हैं कि यह कोड गुणवत्ता के बारे में मेरी बात के साथ कैसे फिट बैठता है, तो मैं जवाब दूंगा: कोड लिखना निरंतर नवाचार के साथ एक प्रक्रिया है, और जब आप किसी विचार को लागू करने का प्रयास करते हैं, तो कोड की गुणवत्ता आपको बहुत परेशान नहीं करती है। हमेशा वापस आना और रिफ्लेक्टर करना आवश्यक है, और यहां तक कि जब मैं ऐसा करता हूं, तो आमतौर पर मेरे लिए कुछ भी काम नहीं करता है। लेकिन इन वर्षों में, मुझे एहसास हुआ कि भले ही मेरा अपना कोड आधार है, लेकिन मैं किसी और के कोड में बहुत खामियां पा सकता हूं। इसलिए, यह दिखावा करने के बजाय कि मेरा कोड पहले से ही बहुत उत्कृष्ट है, मैं इसे उतना ही अच्छा लिखूंगा जितना मैं कर सकता हूं और इसे आपको सत्यापन के लिए दे सकता हूं, जबकि इस बीच मैं अपने सहयोगी का कोड ले लूंगा और जांच करूंगा। परिणामस्वरूप, मेरा कोड और मेरे सहकर्मी का कोड दोनों उच्च गुणवत्ता वाले होंगे।
झूठे अभिमान को छोड़ना बहुत जरूरी है। मैं हमेशा डेवलपर्स को याद दिलाता हूं कि वे एक टीम का हिस्सा हैं, यह एक दूसरे के साथ प्रतिस्पर्धा करने और यह पता लगाने का कोई मतलब नहीं है कि कौन कूलर है, नहीं। मैं ईमानदारी से स्वीकार करने के लिए तैयार हूं कि मेरा ज्ञान काफी सीमित है - लेकिन मैं जो जानता हूं, वह अच्छी तरह जानता हूं। और मेरे सहकर्मी को भी किसी अन्य क्षेत्र में बहुत गहरा ज्ञान है। जब हम एक-दूसरे से सीखने के लिए तैयार होते हैं तो हम और मजबूत होते हैं। इसलिए, मैं हमेशा एक दूसरे के कोड की जांच करने का सुझाव देता हूं, और अतिरिक्त गर्व यहां पूरी तरह से बेकार है। आपको एक-दूसरे के साथ ईमानदार रहने की जरूरत है, यह एक अच्छी टीम के सबसे महत्वपूर्ण गुणों में से एक है। ईमानदारी को दंडित नहीं किया जाना चाहिए अगर कोई व्यक्ति मानता है कि उसने एक बुरा कोड लिखा है - यह सामान्य है। हम कोड को बेहतर बनाने के लिए एक-दूसरे को पेश करके बार बढ़ाते हैं।
एक और महत्वपूर्ण बिंदु: आपको किसी व्यक्ति को यह बताने की आवश्यकता नहीं है कि उसने गलती की है, यह कहा जाना चाहिए कि वास्तव में क्या सुधार किया जा सकता है। यह मत कहो: "भगवान, एक चर के लिए एक भयानक नाम क्या है," यह इस तरह से बेहतर है: "आप शायद यह कहना चाहते थे कि यह चर वितरण की आवृत्ति को दर्शाता है - शायद इसे तदनुसार कहा जाना चाहिए।" इससे आपको अपने इरादों को बेहतर ढंग से समझाने में मदद मिलेगी। यह पुस्तक संपादन पर भी लागू होता है: न केवल उस चीज़ के बारे में बात करें जिसे सुधारने की आवश्यकता है, बल्कि यह भी कि क्या अच्छा किया गया है। हम अक्सर यह भूल जाते हैं। जब मैं किसी और के कोड को संपादित करता हूं और एक ऐसी जगह देखता हूं जिसे अच्छी तरह से निष्पादित किया जाता है, तो मैं एक टिप्पणी में लिखता हूं कि मुझे वास्तव में यह पसंद है, कि हमें इसे अधिक बार करने की आवश्यकता है, और क्यों समझाएं। यह रचनात्मक प्रतिक्रिया बनाता है, यह डेवलपर को स्पष्ट करता है कि आप उसके प्रति शत्रुतापूर्ण नहीं हैं, और अंततः आपकी टीम के कोड की गुणवत्ता में सुधार करते हैं।
- आपने लिखा है कि एक उपकरण का उपयोग करना जो आपको लालसा में ले जाता है, एक जहरीले रिश्ते में फंसने जैसा है: इस स्थिति में, आपको बस छोड़ने की जरूरत है, और जितनी जल्दी हो सके। यह बहुत अच्छा लगता है, लेकिन अक्सर साधन का कोई विशेष विकल्प नहीं होता है, और फिर क्या होता है?- पूरी तरह से न्यायोचित प्रश्न। वास्तव में, ऐसी स्थितियां हैं जहां जाना कहीं नहीं है। लेकिन मैंने उन मामलों के बारे में बात की जब पसंद की संभावना अभी भी है, और केवल इसे बनाने की इच्छा की कमी है। मेरी राय में, यह एक महत्वपूर्ण कारक है।
जब कोई विकल्प नहीं होता है, तो शिकायत करने के बजाय, दर्द बिंदुओं की पहचान की जानी चाहिए: क्या वास्तव में यह उपकरण आपके लिए असुविधाजनक बनाता है। और फिर आप इसे विभिन्न तरीकों से कर सकते हैं। आप डेवलपर्स से संपर्क कर सकते हैं और कह सकते हैं - अपने काम के लिए धन्यवाद, यह हमें लगता है कि यदि आप इस तरह के और इस तरह के पहलू पर ध्यान देते हैं तो आपका उपकरण बहुत बेहतर हो सकता है। या आप हैकाथॉन धारण कर सकते हैं - कई डेवलपर्स के साथ सप्ताहांत पर एक साथ मिलें, एक उपयोगकर्ता समूह को व्यवस्थित करें, उन्हें बताएं कि आप इस उपकरण के साथ दिन में नौ घंटे बिताते हैं, कि यह भयानक है, और उनसे कुछ सुविधाओं को जोड़ने का प्रयास करने के लिए कहें।
शायद आप अकेले सभी समस्याओं को हल नहीं कर सकते हैं, लेकिन कम से कम आप अन्य लोगों को एक साथ ला सकते हैं और उनके साथ इस समस्या को हल कर सकते हैं, खासकर यदि उनके हित आपके समान हैं। अंत में, यदि आपका टूल वास्तव में आपको बहुत सारी समस्याओं का कारण बनता है, तो आप स्वयं एक नया लिखने का प्रयास कर सकते हैं - यदि आपके पास समुदाय में तीन या चार दोस्त हैं, जो आपके समान रवैया रखते हैं।
इसलिए, मेरी राय में, अभी भी विकल्प हैं। आपको जहरीले संबंध बनाने की जरूरत नहीं है। आपको हमेशा एक रास्ता निकालने में सक्षम होना चाहिए - या तो एक साथी के साथ सहमत हों और आपसी समझ हासिल करें, या छोड़ दें।
- आपने लंबोदर के बारे में एक पुस्तक लिखी, और आप इस पुस्तक के लिए जाने जाते हैं। मैं इसे भी पढ़ता हूं, और मुझे विश्वास है कि यह खूबसूरती से लिखा गया है, एप्लिकेशन डेवलपर को क्या चाहिए, और कुछ भी शानदार नहीं देता है। एक सच्चे पेशेवर के रूप में, मैं आपसे पूछना चाहता हूं: आपके लिए कार्यात्मक प्रोग्रामिंग क्या है? क्या आप अपने शब्दों में इसका वर्णन कर सकते हैं? मैं यह सवाल पूछता हूं क्योंकि हर कोई इसे अपने तरीके से थोड़ा परिभाषित करता है, और हर बार छिपे हुए अर्थ सामने आते हैं जो कि विकिपीडिया से मानक परिभाषा से अलग हैं।- यह एक अद्भुत प्रश्न है। इस अवधारणा के बारे में मेरी समझ वर्षों से विकसित हुई है, और अब मेरे लिए कार्यात्मक प्रोग्रामिंग में सबसे महत्वपूर्ण बात यह है कि यह जटिल जटिलता को दूर करता है। हम इस तथ्य के बारे में बात कर रहे हैं कि जरूरी प्रोग्रामिंग में आप न केवल यह इंगित करते हैं कि क्या किया जाना चाहिए, बल्कि यह भी विस्तार से बताएं कि यह कैसे करना है। मेरे लिए, फंक्शनल प्रोग्रामिंग डिक्लेक्टिव प्रोग्रामिंग स्टाइल के लिए एक ऐड-ऑन है, जिसमें हम संकेत देते हैं कि क्या किया जाना चाहिए, लेकिन यह नहीं कहेंगे कि कैसे।
मैं आपको एक आदिम उपमा देता हूं: मेरे सबसे अच्छे दोस्त कारों से प्यार करते हैं, लेकिन वे मुझे बिल्कुल पसंद नहीं करते। जब हम एकजुट होते हैं, तो हम कारों पर चर्चा नहीं करने के लिए सहमत होते हैं, क्योंकि हम दोस्त बने रहना चाहते हैं। मैं एक मैनुअल गियरबॉक्स के साथ कार कभी नहीं चलाऊंगा - गियर को लगातार बदलने की आवश्यकता मेरी पूरी सवारी को खराब कर देती है, और वही प्रोग्रामिंग की अनिवार्य शैली पर लागू होता है। ऑटोमैटिक ट्रांसमिशन ड्राइविंग को थोड़ा आसान बनाता है, लेकिन मेरे लिए सबसे अच्छा विकल्प ड्राइवर के लिए मुझे ड्राइव करना है। इस मामले में, मैं सिर्फ यह कहता हूं कि मुझे कहां जाना है, और जिस तरह से मैं अपने लैपटॉप पर पिछली सीट पर कोड लिखता हूं। मेरे लिए, यह अनिवार्य और कार्यात्मक प्रोग्रामिंग के बीच अंतर है। अनिवार्य प्रोग्रामिंग के साथ, आप स्वयं ड्राइव कर रहे हैं, आपको यह जानना होगा कि कहां जाना है, कैसे जाना है, कहां मुड़ना है, आप कहां कटौती कर सकते हैं। कार्यात्मक प्रोग्रामिंग के साथ, आप पीछे की सीट पर बैठे हैं, ड्राइवर को बता रहे हैं कि आपको कहां ले जाना है, और आपका ध्यान पूरी तरह से आपके काम पर केंद्रित है।
इस बाहरी जटिलता को कैसे हटाया जाता है? कार्यों की संरचना के माध्यम से। फ़ंक्शंस की रचना करते समय, आपका कोड परिवर्तनों की एक श्रृंखला से गुजरता है जिसके दौरान डेटा एक रूप से दूसरे रूप में गुजरता है। इसके अलावा, हमारे लिए यह महत्वपूर्ण है कि इनमें से प्रत्येक चरण को कैसे पूरा किया जाए, लेकिन यह वास्तव में क्या हासिल करता है। मेरे लिए, कार्यात्मक प्रोग्रामिंग का पहला पहलू कार्यात्मक संरचना है। समस्या यह है कि कई भाषाओं में कार्यात्मक संरचना लागू की जाती है - रूबी, पायथन, जावास्क्रिप्ट, ग्रूवी, और इसी तरह - इस कारण लालित्य और अभिव्यक्तता प्रदान करते हैं, लेकिन उनके पास बहुत कम प्रदर्शन है। उनमें कार्यात्मक संरचना को अक्षम रूप से लागू किया जाता है। मेरा मानना है कि दक्षता के बिना लालित्य व्यवहार्य नहीं है। न केवल कोड सुंदर होना चाहिए, यह भी जल्दी से काम करना चाहिए। और यहां हम कार्यात्मक प्रोग्रामिंग के दूसरे, महत्वपूर्ण पहलू पर आते हैं - हम आलसी कंप्यूटिंग के बारे में बात कर रहे हैं। एक निश्चित फ़ंक्शन के परिणाम की गणना केवल उस समय की जाती है जब इसकी आवश्यकता होती है। इसके लिए धन्यवाद, कार्यात्मक प्रोग्रामिंग में लालित्य और दक्षता का एक संयोजन प्राप्त किया जाता है। तो, मेरे लिए, कार्यात्मक प्रोग्रामिंग क्या करना है पर जोर है, न कि कैसे करना है; डेटा परिवर्तनों की एक श्रृंखला के रूप में कार्यात्मक रचना का उपयोग; और आलसी कंप्यूटिंग के लिए कुशलता से इन परिवर्तनों को करने की क्षमता।
कृपया ध्यान दें कि मैंने प्रतिरक्षा और उच्च-क्रम के कार्यों के बारे में बात नहीं की। तथ्य यह है कि वे केवल मेरे द्वारा वर्णित परिणाम प्राप्त करने के लिए सामग्री हैं। हम प्रतिरक्षा और उच्च-क्रम के कार्यों के लिए कार्यात्मक प्रोग्रामिंग का उपयोग नहीं करते हैं, वे केवल एक उच्च लक्ष्य को प्राप्त करने के लिए एक साधन हैं: एक्सट्रूज़न जटिलता से छुटकारा।
- महान परिभाषा। आज एक भाषा है जो कार्यात्मक प्रोग्रामिंग के लिए मानदंड है: हास्केल (और संभवतः एफ #)।- ठीक है।
"कम से कम बहुत से लोग ऐसा सोचते हैं।" लेकिन जावा स्पष्ट रूप से हास्केल नहीं है, यह काफी हद तक सीमित है। क्या जावा पर लागू होने पर कार्यात्मक प्रोग्रामिंग एक अनुशासन के रूप में समझ में आता है? आखिरकार, हमारी भाषा में इस दृष्टिकोण के लिए बहुत सीमित उपकरण हैं।- मेरे लिए, उत्कृष्टता की खोज के बजाय व्यावहारिक पहलू अधिक महत्वपूर्ण है। मैं पूर्णता के बारे में उत्सुक हूं, लेकिन काम करने के लिए मुझे हर चीज के लिए एक व्यावहारिक होना होगा। मैं हास्केल के बारे में पागल हूं और उसके साथ बहुत समय बिताता हूं, बस यह पता लगाने के लिए कि कार्यात्मक प्रोग्रामिंग में किसी विशेष कार्य को कैसे हल किया जाता है। लेकिन अपने ग्राहकों के लिए मैं हास्केल पर नहीं लिख रहा हूं। यहां आप "कैथेड्रल और बाज़ार" के साथ एक सादृश्य आकर्षित कर सकते हैं। कैथेड्रल सुंदर है, लेकिन ज्यादातर समय मैं बाजार में बिताता हूं। सवाल यह है कि इस दुनिया में कैसे बचे। जब भाषाएं विकसित होती हैं और जब हम कई अलग-अलग प्रतिमानों को एक साथ संयोजित करने का प्रयास करते हैं, तो हमें, प्रोग्रामर के रूप में, उनके कार्यान्वयन के साथ बेहद सावधान रहने की आवश्यकता होती है।
मुझे नहीं लगता कि जावा में कार्यात्मक प्रोग्रामिंग बिल्कुल भी असंभव है। उन स्थितियों में जहां एक विकल्प है, मैं मेरे लिए सबसे उपयुक्त भाषा पर ध्यान केंद्रित करूंगा। लेकिन मैं क्लाइंट को कभी नहीं बताऊंगा: आपको इस भाषा का उपयोग करना चाहिए। सबसे अधिक बार मैं पूछता हूं कि वे वास्तव में क्या करते हैं, और पर्यावरण के ढांचे के भीतर एक और अधिक इष्टतम तरीके से ऐसा करने का तरीका खोजने की कोशिश करें जो उनके पास पहले से है। मेरा मानना है कि जावा जैसी भाषाओं में अनिवार्य और कार्यात्मक प्रोग्रामिंग का संयोजन काफी संभव है और यहां तक कि सिफारिश भी की जाती है, लेकिन यह अत्यधिक सावधानी के साथ किया जाना चाहिए। कल्पना करें कि आपके पास शुद्ध कार्यों का एक प्रकार का चक्र है, जिसके चारों ओर अशुद्धता की अंगूठी होगी। सब कुछ जिसे आप परिवर्तनशील बनाना चाहते हैं, वह सर्कल के बाहर होना चाहिए। इस घेरे के अंदर, आप अपनी स्वयं की श्रृंखलाओं को कार्यान्वित कर सकते हैं, लेकिन सभी परिवर्तन इसके बाहर होने चाहिए।
यह एक कारण है कि मुझे नई भाषाओं को सीखने में मज़ा आता है। मैं हाल ही में एल्म भाषा से परिचित हुआ, जो एफ # इंटरसेपर्स के साथ हास्केल सिंटैक्स है जो जावास्क्रिप्ट में संकलित है। इस दृष्टिकोण ने मुझे शुरू से ही दिलचस्पी दी, क्योंकि जावास्क्रिप्ट एक बाज़ार है। जब आप जावास्क्रिप्ट के माध्यम से यात्रा करते हैं, तो आप लगातार puddles में कदम रख रहे हैं। हास्केल के सिंटैक्स के लिए धन्यवाद, एल्म निश्चित रूप से एक गिरजाघर है। फिर भी, इस संक्षिप्त कोड को बाज़ार में चलाना संभव है। एल्म की वास्तुकला सुरुचिपूर्ण है, इसमें एक मॉडल है (जो डेटा है), एक दृश्य है जो इस डेटा को प्रदर्शित करता है, और एक परिवर्तन है, अपडेट है। पहला मुख्य सिद्धांत यह है कि डेटा को देखने में संग्रहीत किया जाता है। जब उपयोगकर्ता एक क्रिया करता है (उदाहरण के लिए एक कुंजी दबाता है), तो दृश्य से डेटा को अपडेट फ़ंक्शन में भेजा जाता है, जहां रूपांतरण होता है। डेटा अपरिवर्तनीय है, और अपडेट फ़ंक्शन नया डेटा देता है जो दृश्य पुराने के बजाय सहेजता है।
यदि आप इसके बारे में सोचते हैं, तो ठीक उसी तरह से Redux कार्य करता है। इसमें डेटा हैं और रिड्यूसर मौजूद हैं। जब डेटा रिड्यूसर्स को भेजा जाता है, तो आपको बदले में एक नई कॉपी मिलती है, जिसे आप पुराने के बजाय बचाते हैं। लेकिन अगर एल्म और रेडक्स एक ही योजना पर काम करते हैं, तो उसी योजना को जावा में लागू किया जा सकता है। हम शुद्ध कार्य बना सकते हैं जो डेटा लेगा, उसे रूपांतरित करेगा और एक नई प्रति लौटाएगा। Redux और Elm से सीखकर, हम Java आर्किटेक्चर को अधिक कार्यात्मक बना सकते हैं। मैं इस बारे में बात कर रहा हूं क्योंकि Redux जावास्क्रिप्ट में संकलित है, जो विशिष्ट रूप से एक बाज़ार है। जावास्क्रिप्ट, मुझे लगता है, कार्यात्मक शुद्धता के आदर्श से सबसे दूर है, यहां हर कदम पर आप एक पोखर में कदम रखते हैं। फिर भी, Redux आपको इस बेहद अशुद्ध दुनिया में कार्यात्मक शुद्धता प्रदान करता है। इस दृष्टिकोण ने मुझे बहुत प्रभावित किया क्योंकि इसने कार्यात्मक प्रोग्रामिंग के बारे में मेरा दृष्टिकोण बदल दिया और दिखाया कि मैं इन सिद्धांतों को जावा में भी लागू कर सकता हूं।
- अच्छा, धन्यवाद। आपकी राय में, हमारे पास जावा में पूर्ण और पर्याप्त उपकरण का पूरा सेट है? क्या हमें लंबोदर भाव, विधि संदर्भ, धाराओं के साथ संग्रह के अलावा कुछ और चाहिए?- मेरी राय में, हमें अभी भी बहुत कुछ याद करना है। जावा दुनिया लगातार विकसित हो रही है। मैंने हाल ही में एक शख्स से बातचीत की, जिसने कहा: "मैंने सुना है कि आप कुछ साल पहले हमारे शहर में थे और जेनरिक के बारे में बहुत तर्क दिया," जिस पर मैंने जवाब दिया: "मैं हमेशा जेनेरिक के बारे में बहुत बहस करता हूं।" मेरा मानना है कि जावा जेनरिक में बहुत खराब तरीके से काम किया जाता है। ब्रायन गोएट्ज़ हर समय मुझसे नाराज़ रहते हैं: "हमेशा कोई ऐसा व्यक्ति होगा जो जेनरिक के बारे में शिकायत करता है," और यह एक, निश्चित रूप से, मैं हूं। मेरी राय में, इस क्षेत्र में बहुत सुधार किया जा सकता है। मेरी राय में, सुधार बहुत महत्वपूर्ण है। बहुत कम किया जा सकता है पेट फूलना को कम करने के मामले में, बॉयलरप्लेट कोड से छुटकारा पाने के। कोड को बहुत अधिक धाराप्रवाह बनाया जा सकता है। और इस दिशा में एक निश्चित आंदोलन आज पहले से ही दिखाई दे रहा है। जावा अब पैटर्न मिलान को लागू करता है, जो मुझे बहुत खुश करता है - मुझे वास्तव में पसंद है कि यह कैसे स्काला और कोटलिन में लागू किया जाता है। मुझे लगता है कि यह बहुत महत्वपूर्ण है, और एक बैंकनोट प्रसंस्करण मशीन के साथ सादृश्य मेरे दिमाग में आता है। यदि आप इसके माध्यम से नोटों का एक बंडल पास करते हैं, तो यह उन्हें प्रत्येक बैंक नोट के मूल्य के अनुसार क्रमबद्ध करेगा। इसी तरह, प्रोग्रामिंग कार्यों में पैटर्न मिलान। आप मापदंडों के माध्यम से डेटा पास करते हैं जो प्रसंस्करण के लिए डेटा पुनर्प्राप्त कर सकते हैं। मुझे लगता है कि यह जावा में लिखने वाले बड़ी संख्या में शाखा ऑपरेटरों से छुटकारा पाने में मदद कर सकता है। कोड बहुत अधिक अभिव्यंजक बन जाएगा। सामान्य तौर पर, मेरा मानना है कि जावा को बहुत सारे अतिरिक्त की आवश्यकता है, लेकिन, जाहिर है, यह पहले से ही इस दिशा में आगे बढ़ रहा है।
मैं एक और पहलू का उल्लेख करना चाहता हूं जो वास्तव में मेरे लिए उत्सुक है। मैं पारंपरिक प्रोग्रामिंग की दुनिया में बड़ा हुआ हूं। मैं सार्वजनिक रूप से यह स्वीकार करने से नहीं डरता कि मेरी पहली भाषा विज़ुअल बेसिक थी। एक मायने में, यह पहले प्रयोग के लिए एक अच्छी भाषा है, क्योंकि यह किसी भी बदतर नहीं हो सकता है। फिर मैंने C और C ++ में लंबे समय तक लिखा, और अधिकांश समय मैंने C ++ के साथ बिताई सभी भाषाओं से। उसके बाद, मैंने जावा, सी # में लिखना शुरू किया, रूबी जैसी भाषाएँ। एक निश्चित बिंदु पर, मैंने महसूस किया कि मैंने हमेशा मल्टीथ्रेडिंग वाली भाषाओं में लिखा है। इसलिए नोड को जानना एक तरह की अंतर्दृष्टि थी - अतुल्यकालिक प्रोग्रामिंग का पता लगाने से पहले मुझे कुछ समय लगा। , , — , Java. (coroutines) (continuations). , Java , , , . , Java , . , . . , , , , Java-, . , , , . Java , .
— , ? JVM-, . . ?— , . , . , , : , , , , , . , . . , , , , . Big Data. , . , . , , , -. , , . , .
, , . , . , . , , . , , , . , , , . . , , : . , 30 . , -, .
, . , , , . . . , , , . : , . , , .
— . , ? , , . , Reactive Streams, Spring Reactor, CQRS event sourcing. - , CQRS?— , , . , , — . Angular 1, , , . Angular «$» . , : « . ». , . , , , . , . — — Angular 2, , .
, , . , , API — . ? - ? , , - . . Java — — deprecated-. Angular 1 — . , , .
— - (event-driven systems), , . , -. , , API , . , . , , 5-10 , . -, , - . , . , , — , . — ++. — . , , , . - , , , . , , , .
— , , .
Java Champions, Microsoft MVP, JavaScript, . : Java ? .NET, JavaScript - ?— , Java , .NET - . # Java, , C# . . Java , # LINQ, , (, Func). C# , Java. , , Java 2014 CompletableFuture. C# .
Java JavaScript. , « JavaScript» , JavaScript , . «callback hell», , - , . JavaScript Promises (), CompletableFutures Java. : , . Promises , . — Promises . , , , . , , , , . JavaScript async await. , Promise. , , , , , . CompletableFuture , continuations Java . , coroutines Kotlin.
, , . . , , , , , , . , , . , , — , , . async C#, async/await Promises JavaScript coroutines Kotlin, , , — , , . . Java . , Java , , , , . , . , , , . Java , . , Java — .
Java. . , Java , . Java , invokedynamic, , . , JVM. Java , — . , , . , Java , Java , JVM. . , , . , Java , .
— . , , , . , 5 . — . — , Common Lisp, JavaScript Meta Object Protocol, DSL Kotlin JetBrains MPS, GraalVM Java Java . . ?— . , . , , . . -, , . -, , . , , , . , . , , . , , . , , : ? — ? , , ? , . : , Angular, — React? , React. — ? , , , , - , . , , . , , . , , — , , . , .
, . , . - : , . , : , , , , . 1 10, 10 « », 1 «». 1 10, 1 « », 10 — « ». , , . , . , . , Angular, React Java . : ? , . , : . . , , , . , , , , ; ; .
, , — . — , . . - , , . , , . , . , , . , , . , . , , , .
— , . Joker , .— , .
