यह निर्धारित करना कि क्या भाषा / रूपरेखा / तकनीक 'फ्यूचर-प्रूफ' है

Question

मैं एक PHP डेवलपर हूं और मैंने हाल ही में CodeIgniter के साथ काम करना शुरू किया है। ऐसा लगता है कि जब भी मैं CodeIgniter से संबंधित कुछ खोजता हूं, तो ब्लॉग पोस्ट और आमतौर पर '09 या '10 से क्या नहीं होता है, इसलिए यह मुझे सोच रहा है, क्या CodeIgniter अभी भी प्रासंगिक है और क्या यह भविष्य में होने वाला है? क्या एक और ढांचा है जो जगह ले रहा है?

वही अन्य भाषाओं और रूपरेखाओं के लिए भी जाता है। किस बिंदु पर आप कुछ भाषाओं या रूपरेखाओं को सीखना छोड़ देते हैं? क्या उन लोगों को खोजने का कोई आसान तरीका है जो उभर रहे हैं और उन्हें लेने लायक हैं?

Comments

मुझे मेरी क्रिस्टल बॉल से सलाह लेने दो ...

— FrustratedWithFormsDesigner

@MotiveKyle एक त्वरित खोज ने मुझे इस ... tiobe.com/index.php/content/paperinfo/tpci/index.html पर यकीन नहीं दिलाया कि अगर यह मददगार है, लेकिन इसकी दिलचस्प बात कम नहीं है।

— Ominus

@MotiveKyle मुझे लगता है कि अंतर्निहित मुद्दा (और मैं इससे पीड़ित हूं) "क्या मैंने उस समय / प्रयास के लायक सीखने के लिए चुना है जिसे मैं इसमें डालने जा रहा हूं?"। इतने सारे विकल्पों के साथ यह पता लगाना भारी पड़ सकता है कि हमारे चुने हुए लाइन में सबसे बड़ी अदायगी के लिए समय / ऊर्जा का निवेश करना कितना अच्छा है।

— Ominus

यही मेरे मन में था। बहुत बुरा वे सूचीबद्ध फ्रेमवर्क नहीं है!

— काइल

COBOL वहाँ सबसे भविष्य की प्रूफ तकनीकों में से एक है। कोबोल स्थापित बेस बहुत दूर जाने की संभावना नहीं है। आप सोच सकते हैं कि इसका क्या मतलब है।

— user16764

Answer 1

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

लेकिन मैं निम्नलिखित सभी की तलाश करूंगा:

• स्थापित आधार - एक बड़ा स्थापित आधार का मतलब है कि बहुत सारी कंपनियां प्रौद्योगिकी और इसके रखरखाव में निवेश करने के लिए संघर्ष करेंगी, जिसका अर्थ है कि डेवलपर्स को तकनीक के साथ काम करने की आवश्यकता होगी। सकारात्मक चक्र ensues। उदाहरण के लिए, जावा, इससे पहले COBOL की तरह, बहुत लंबे समय के लिए दूर नहीं जा रहा है ।
• व्यापक उद्योग आधारित समर्थन - क्या कई बड़े नाम उद्योग के खिलाड़ी प्रौद्योगिकी का समर्थन कर रहे हैं? केवल एक प्रतिबद्ध बैकर एक चेतावनी संकेत है - यह रणनीति के एकल परिवर्तन के साथ किसी भी समय गिरा या दरकिनार किया जा सकता है।
• ओपन सोर्स - प्रमुख ओपन सोर्स उत्पाद बहुत अच्छे दीर्घकालिक दांव साबित हुए हैं (उदाहरण के लिए लिनक्स, अपाचे, रेड हैट, जेबॉस, एक्लिप्स को देखें ...)। दूसरी ओर मालिकाना उत्पाद कुछ हद तक एक एकल विक्रेता के चक्कर में होते हैं, जहां आपको अपनी "अगली बड़ी चीज़" के लिए पलायन करने के लिए कीमतों / बंद करने की कोशिशों / कीमतों में वृद्धि का खतरा होता है।
• गुणवत्ता - उच्च गुणवत्ता वाले उत्पाद केवल लंबे समय तक जीवित रहेंगे क्योंकि लोग उन्हें किसी और चीज़ पर स्विच करने के बजाय उनका उपयोग करना चाहेंगे । इसके विपरीत, कम गुणवत्ता वाले उत्पादों को छोड़ दिया जाएगा जैसे ही कुछ बेहतर होगा।
• नवाचार - नवाचार की अत्याधुनिक तकनीक है? यदि ऐसा है, तो अधिक नवीन कंपनियों और उपयोगकर्ताओं के बीच इसे अपनाने और समर्थन प्राप्त करने की संभावना है। यह अंततः मुख्यधारा बनना शुरू हो जाएगा (मैं उदाहरण के लिए स्काला और क्लोजर जैसी नई भाषाएं कहूंगा)
• समुदाय - यह तकनीक के आसपास एक सकारात्मक, खुले दिमाग, व्यावहारिक, प्रतिबद्ध, सहायक समुदाय है? ये वे लोग हैं जो अंततः भविष्य की गारंटी देंगे ....।

Comments

तो आप VB6 की व्याख्या कैसे करते हैं? ;-)

— sdg

काला जादू.....?

— मिकेरा

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

— आर्सेनी मूरज़ेंको

@ मेनमा: चूंकि ओपन सोर्स लोकप्रियता में बढ़ रहा है और विंडोज लोकप्रियता में गिर रहा है, ऐसा लगता है कि सबूत है। "हजारों सबसे लोकप्रिय उत्पाद दीर्घकालिक दांव नहीं हैं" सही। बहुत सारे और बहुत सारे उत्पाद पांच साल में नहीं होंगे। "भयानक स्पेगेटी कोड, लेकिन अभी भी लोकप्रिय हैं।" क्या आपने जवाब पढ़ा? "जब तक] कुछ बेहतर साथ आता है"। PHP के लिए कुछ भी बेहतर नहीं है? इसलिए। विरासत कायम है।

— S.Lott

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

— साइमन बर्गोट

Answer 2

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

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

Comments

चूँकि भविष्य बहुत कठिन है, इसलिए यह समझना कठिन है कि "भविष्य-प्रमाण" का क्या अर्थ हो सकता है। "मुझे लगता है कि लगभग पांच कंप्यूटरों के लिए एक विश्व बाजार है '- थॉमस जे वाटसन (अंतर्राष्ट्रीय व्यापार मशीनों के बोर्ड के अध्यक्ष) को जिम्मेदार ठहराया, 1943"।

— S.Lott

Answer 3

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

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

Answer 4

"फ्यूचरप्रूफ-इनसे" इच्छा-शक्ति और हठ के बारे में अधिक है क्योंकि यह अधिक व्यावहारिक चिंताओं के बारे में है।

एक चरम उदाहरण यह है । स्पार्कल फिल्टर 40 के अंत से उनके लेखांकन प्रणाली के रूप में एक आईबीएम 402 कंप्यूटर रनिंग है। यह एक मशीन है जिसे "फाइल" के बजाय विद्युत प्लग-बोर्ड का उपयोग करके प्रोग्राम किया जाता है।

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

मैं कहूंगा कि अगर आपकी कंपनी को कंप्यूटर इतिहास संग्रहालय से एक यात्रा मिलती है, जैसे स्पार्कल फिल्टर ने किया, तो यह एक संकेत होगा कि आपने (या आपके पूर्वजों) सिस्टम को सफलतापूर्वक "भविष्य-प्रूफ" किया है!

Comments

शब्द 'भविष्य-सिद्ध' होना चाहिए, शायद :)

— 9000

Answer 5

मैं जवाब दे सकता हूं कि क्या कोई विशेष तकनीक भविष्य का प्रमाण है - इसका उत्तर लगभग निश्चित रूप से नहीं है, क्योंकि आपने इस पर कोई समयसीमा नहीं लगाई है।

इस प्रश्न को उत्तर देने योग्य बनाने के लिए आपको आवश्यकताओं में कुछ और विस्तार करने की आवश्यकता है। उदाहरण के लिए:

• हम किस समयसीमा के बारे में बात कर रहे हैं - 1 वर्ष, 3 वर्ष, 5+ वर्ष?
• 5 साल के समय में ऐसा कुछ लेने की लागत क्या होगी?
• कम "सुरक्षित" विकल्प चुनने से आपको क्या लाभ होगा, और क्या लाभ जोखिम को कम करते हैं?

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

जीवन में अधिकांश चीजों की तरह, सबसे कम जोखिम वाली गतिविधि वास्तव में सबसे अच्छा विकल्प नहीं हो सकती है।

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

भविष्य में आप जितनी देर देखना चाहते हैं, उतनी कम निश्चितता होने वाली है। यदि आप उदाहरण के लिए अगले 2 वर्षों के बारे में केवल चिंता करने से खुश हैं, तो आपकी पसंद को अगले 10 वर्षों के लिए कुछ और लेने की तुलना में बनाने (और आपके लिए बहुत अधिक विकल्प छोड़ना) आसान हो जाएगा।

Answer 6

इसके बहुत सारे कारक हैं जो मैं कहूंगा कि यह असंभव है। जो चीजें गलत हो सकती हैं उनमें शामिल हैं: -

• फैशन। लोग रुचि खो देते हैं और एक नए प्रेटियर प्लेटफार्म की ओर ध्यान देते हैं। पर्ल के पास वेब एप्लिकेशन लगभग 2000 का एकाधिकार था। अब इसका उल्लेख मुश्किल है।
• विक्रेताओं के बाजार में हिस्सेदारी। लगभग 2000 आपके पास होगा हालांकि सी ++ / सन सोलारिस वर्ष 3000 तक अच्छा था।
• कॉर्पोरेट शेनानीगन्स। कुछ साल पहले मैंने जावा को भविष्य के प्रमाण मंच के रूप में चुना होगा। ORACLE ने एपीआई आदि को कॉपीराइट करने के साथ मुझे लगता है कि कुछ अन्य भाषा ढांचे के लिए दूर जाना होगा, मैं बस इच्छा करता हूं कि मुझे पता था कि कौन सा है।
• सड़क के अंत। मैं विजुअल बेसिक जैसी चीजों के बारे में सोच रहा हूं, जो एक लंबे और सम्मानजनक इतिहास के बाद सॉफ्टवेयर विकास में नवीनतम सोच को समायोजित करने के लिए और अधिक नहीं बढ़ाया जा सकता है।
• हारने वाला जीत जाता है। PHP (जो मुझे पसंद है) ने कभी भी डेवलपर्स के बीच कोई सौंदर्य प्रतियोगिता नहीं जीती, लेकिन यह वेब के निर्विवाद राजा के रूप में उभरा है। जब मैंने पहली बार 2004 में कुछ php लिखा था तो मैंने इसे कभी भी वेब डेवलपमेंट के linga franca के रूप में समर्थित नहीं किया।
• बदसूरत बत्तखें। सिंटैक्स के एक टुकड़े को बदलने या एक एपीआई जोड़ने के बिना जावास्क्रिप्ट, अचानक एक होके स्क्रिप्टिंग भाषा से चला गया जो एनिमेटेड कष्टप्रद बैनर WEB 2.0 के केंद्र टुकड़े में जोड़ता है।

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

Answer 7

एक PHP फ्रेमवर्क, सिम्फनी ने अपनी साइट पर इसे पूरी तरह से समझाया ।

सही रूपरेखा चुनने के लिए 10 मापदंड

आप प्रगति कर रहे हैं और यह एक अच्छी बात है! आप पहले से ही जानते हैं कि आप अपनी साइट या अपने एप्लिकेशन को विकसित करने के लिए एक रूपरेखा का उपयोग करने जा रहे हैं। लेकिन कौन सा? यहाँ एक चेकलिस्ट है जिसका उपयोग आप गलती करने से बचने के लिए कर सकते हैं:

1. विशिष्टता और सामुदायिक आकार

फ्रेमवर्क जितना अधिक जाना जाता है और पहचाना जाता है, उतना ही यह "जीवित", विकसित और पूर्ण होगा: नए विचार, प्लग-इन की संख्या और गुणवत्ता, आदि।

2.Philosophy

यह रूपरेखा का बहुत सार है: यह सुनिश्चित करने के लिए एक मौलिक मानदंड है कि यह आपकी आवश्यकताओं को पूरा करेगा। अपनी जरूरतों के लिए पेशेवरों द्वारा विकसित एक उपकरण स्पष्ट रूप से अन्य पेशेवरों की मांगों को पूरा करेगा।

3.Sustainability

एक फ्रेमवर्क चुनने से पहले, सुनिश्चित करें कि यह आपके लिए अवधि तक बनाए रखने में सक्षम होगा। यह आपके अनुप्रयोगों के रखरखाव और उन्नयन दोनों को सरल करता है।

4.Support

एक और मानदंड जिसे अनदेखा नहीं किया जाना चाहिए, वह है आपके सवालों के जवाब खोजने और मदद पाने में आसानी। उपलब्ध समर्थन को पहचानें: प्रकाशक से। एक समुदाय से (मेलिंग सूचियों, आईआरसी, आदि)? सेवा कंपनियों (विकास, समर्थन, प्रशिक्षण) से?

5.Technique

एक भूलभुलैया में फंसने से बचने के लिए, हमेशा एक अंतर समाधान चुनना बेहतर होता है; एक जो विकास के संदर्भ में सर्वोत्तम प्रथाओं का सम्मान करता है (डिजाइन पैटर्न)

6.Security

कोई भी एप्लिकेशन संभावित रूप से असुरक्षित है। जोखिम को कम करने के लिए, सुरक्षा कार्यों को सुनिश्चित करने में सक्षम ढांचे का चयन करना हमेशा बेहतर होता है (उदाहरण के लिए XSS प्रबंधन)।

7.Documentation

एक ढांचे के बारे में मौजूदा साहित्य की प्रकृति, मात्रा और गुणवत्ता का मूल्यांकन करना एक परम आवश्यकता है: एक अच्छी तरह से प्रलेखित उपकरण का उपयोग करना आसान है और अधिक उन्नयन योग्य है।

8.License

लाइसेंस महत्वपूर्ण हैं, क्योंकि वे आपके अनुप्रयोगों पर महत्वपूर्ण प्रभाव डाल सकते हैं। उदाहरण के लिए, जीपीएल-लाइसेंस प्राप्त ढांचे का उपयोग करके विकसित एक आवेदन आवश्यक रूप से जीपीएल के अधीन होगा। दूसरी ओर, यह एमआईटी-लाइसेंस प्राप्त ढांचे के लिए मामला नहीं है।

9. बाजार पर संसाधनों की उपलब्धता

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

10. इसे बाहर निकालो!

यही कुंजी है! इंटरनेट पर अच्छे या बुरे, समीक्षाओं, टिप्पणियों और अफवाहों को पढ़ने से संतुष्ट न हों। इसका परीक्षण करके, आप अपना स्वयं का मन बना पाएंगे और सुनिश्चित करेंगे कि आप उपकरण के साथ पूरी तरह से सहज हैं।

Answer 8

कुंजी धैर्य है। धैर्य, संयम, धैर्य। भविष्य का अनुमान लगाने का कोई तरीका नहीं है। (क्या मुझे भी ऐसा लिखना है?) लेकिन अगर आप नई तकनीक को कुछ साल देते हैं और देखते हैं कि कैसे इसे अपनाया जाता है, तो आपको इस बात का अंदाजा होगा कि यह जड़ें लेगा या नहीं, दीर्घकालिक परियोजनाओं / समय निवेश के लिए उपयुक्त है ।

इसलिए जब NextNewThing (tm) चारों ओर आता है, तो बैंडवागन पर कूदने के लिए स्वतंत्र महसूस करें ... बस कुछ वर्षों के लिए कुछ भी महत्वपूर्ण नहीं है।

Answer 9

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

1. डेटा को एक खुले प्रारूप में संग्रहीत किया जाना चाहिए जो बाद में निकालने या बदलने में आसान हो। अजीब फ़ाइल प्रारूप सामान्य रूप से एक बड़ी लॉकइन तकनीक और जाल क्षेत्र हैं। इसके अलावा, CSV, ASN.1, या JSON जैसे जटिल क्रैप जैसे XML या कहें, Word 97 प्रारूप;) जैसे सरल तरीकों को प्राथमिकता दें। विचार यह है कि अपने आप से एक पार्सर को एक साथ फेंकना काफी सरल है और निम्न-स्तरीय प्रारूप पार्सर आपके एप्लिकेशन में पुन: प्रयोज्य है।

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

3. स्टैक पूरी तरह से खुला स्रोत होना चाहिए और संशोधित करने के लिए स्वतंत्र होना चाहिए । जीपीएल, एलजीपीएल, बीएसडी, एमआईटी, आदि लाइसेंस इस कोण पर ठीक हैं। यह विचार यह है कि, यदि समुदाय मरना शुरू कर देता है, तो स्टैक को नए [हार्डवेयर / ओएस / प्रोटोकॉल / आदि] में ले जाने की आवश्यकता हो सकती है। और आपको ऐसा करने के लिए कोड की आवश्यकता है।

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

5. आपके एप्लिकेशन को एक मॉड्यूलर तरीके से बनाया जाना चाहिए जो उस क्षेत्र में पुन: कार्य को कम करने के लिए प्लेटफ़ॉर्म विवरणों को बताता है। यह इनपुट / प्रोसेसिंग / आउटपुट ब्लॉकों में फ़ंक्शंस को संरचना में मदद करता है जहां संभव हो। यह एक पोर्ट से प्रभावित होने के विश्लेषण के लिए सहायता कर सकता है (और सामान्य रूप से एक ला 'Cleanroom पद्धति) में शुद्धता विश्लेषण। सबसे कम जोखिम वाला दृष्टिकोण प्लेटफ़ॉर्म वार न्यूनतम आम भाजक सुविधाओं का उपयोग करना है जो सार्वभौमिक रूप से एक इंटरफ़ेस के साथ समर्थित हैं जो आपको उनका उपयोग करने देता है, आगे पोर्टिंग को कम करता है। (मैंने कहा कि आप कुछ खो देंगे ...)

6. डायनामिक टाइपिंग, टाइप इंट्रेंस या अन्य लचीले टाइपिंग दृष्टिकोण मदद करते हैं। एक नए प्लेटफ़ॉर्म पर पोर्ट आधार प्रकार की परिभाषा बदल सकता है। आंतरिक रूप से मजबूत टाइपिंग करने वाली भाषाओं का मतलब है कि आप इस सामान के साथ कम चिंता करते हैं।

7. कंसीलर मॉडल को सरल रखें। घटना-चालित, स्पष्ट इंटरफेस से गुजरने वाला संदेश पोर्टेबल है ... मूल रूप से सब कुछ। वहाँ भी coroutines है। आप बस उन मार्गों से बचना चाहते हैं जो त्रुटियों और पोर्टेबिलिटी दोनों समस्याओं से ग्रस्त हैं।

8. मोज़िला और अपाचे के पोर्टेबल रनटाइम्स को देखें। वे कुछ इंटरफ़ेस और कार्यान्वयन विकल्पों के साथ कई प्लेटफ़ॉर्म विशिष्ट मुद्दों को कारक बनाते हैं। कई समस्याओं के अच्छे समाधान प्रदान करने के साथ-साथ वे किस चिंता में घिर सकते हैं।

सही उदाहरण: Tcl। मुझे पता है, बहुत से लोग इसे नफरत करते हैं और मैं शायद ही कभी इसका इस्तेमाल करता हूं। फिर भी, Tcl (12 मुख्य नियमों) को समझने, लागू करने और कोड करने के लिए एक बेहद आसान भाषा है। यह छोटा है, काफी तेज है, वेब सर्वर के साथ एकीकृत है, देशी ऐप्स में एम्बेड किया गया है, सामान के टन में पोर्ट किया गया है, इसमें कुछ सुरक्षा विशेषताएं हैं , और 80 के दशक के बाद से नियमित रूप से अपडेट किया गया था जब इसे बनाया गया था। आप या मैं कोर भाषा के लिए कुछ ही समय में एक पूरे टीसीएल रनटाइम को लागू कर सकते हैं। यदि हमें मानक पुस्तकालय को पोर्ट करना है, तो यह .NET या जावा को पोर्ट करने से अधिक आसान होगा। और इसके लिए काफी उपयोगी कोड लिखा गया है। और इसका उपयोग वेब तकनीक में "मोबाइल एजेंट" के रूप में किया जाता है जो कि जावा एप्लेट का भी उद्देश्य है। उदाहरण के लिए, OpenACS वेब फ्रेमवर्क 1998 से पुराने सर्वर से वापस चला जाता है।

अन्य उदाहरण: BASIC, COBOL और LISP (स्कीम या CL)। ये सभी भाषाएं 50 या 60 के दशक की ओर वापस चली जाती हैं। वे समझ, कार्यान्वयन और यांत्रिक अनुवाद को आसान बनाने के लिए पर्याप्त सरल हैं। फिर भी, आप उनके साथ उपयोगी सामान बना सकते हैं। COBOL अभी भी दुनिया के अधिकांश लेन-देन प्रसंस्करण का अधिकार देता है, कुछ बार अपडेट किया गया है, और .NET पर भी चलता है। पुराने QBasic / QuickBASIC एप्लिकेशन अभी भी आधुनिक प्लेटफार्मों पर खुले / मुफ्त टूल के साथ चल रहे हैं, साथ ही GAMBAS या RealBASIC जैसे बेहतर टूल की संभावनाओं को चित्रित करते हैं। LISP कोडर्स स्वाभाविक रूप से अपने सिस्टम को मॉड्यूलर और कार्यात्मक बनाते हैं, पोर्टिंग को आसान बनाते हैं। दशकों से, खुले और वाणिज्यिक रूप से इसके लिए कार्यान्वयन की एक स्थिर धारा रही है।

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