- Swift को OS में शामिल करने से डेवलपर्स के लिए स्थिति और खराब हो गई, ऐसी शिकायत Swift फ़ोरम में उठाई गई
- इसके जवाब में एक व्यंग्यात्मक टिप्पणी आई कि OS के साथ आने वाली लाइब्रेरीज़ की दुनिया में आपका स्वागत है
- यह लेख Apple में Swift विकसित करने के अनुभव के आधार पर बताता है कि Swift के OS का हिस्सा बनने की पृष्ठभूमि क्या थी और इससे कौन-सी समस्याएँ पैदा हुईं
OS निर्भरता
- पहले पर्सनल कंप्यूटर चल रही process को पूरी मशीन नियंत्रित करने की अनुमति देते थे, लेकिन अब operating system kernel हमेशा चल रहा होता है और बुनियादी OS services देता है
- अधिकांश आधुनिक OS ऐसे program बनाने की अनुमति देते हैं जो system call interface के ज़रिए कुछ विशेषाधिकार वाले कामों का अनुरोध कर सकते हैं.
- आज के Apple OS में system call interface, OS version के अनुसार स्थिर नहीं है, इसलिए बुनियादी काम करने के लिए C/POSIX standard library और उसके extensions का उपयोग करना पड़ता है.
Apple का मॉडल (Swift से पहले)
- Swift से पहले Apple के अधिकांश public API, C या Objective-C में लिखे जाते थे और native code के रूप में दिए जाते थे.
- नया OS version मौजूदा libraries के नए binary-compatible version शामिल करता था, जिससे API के पुराने version भी शामिल रहने वाला एक superset मिलता था.
- इस मॉडल की मुख्य कमी यह थी कि नए features और API नए OS version से बंधे रहते थे.
Swift "बीटा" 1 ~ 5
- Swift 1 से Swift 5 तक बहुत बदलाव हुए, और ABI stability हमेशा Swift का लक्ष्य रही.
- Swift 5 तक आते-आते अधिकांश समस्याएँ हल हो गईं, और यह भी सोचना पड़ा कि Swift को OS में शामिल करने पर मौजूदा apps और projects प्रभावित न हों.
संक्रमण
- Swift को OS में शामिल करने की प्रक्रिया में यह रास्ता ढूँढ़ना पड़ा कि पहले से बने apps और projects टूटें नहीं.
rpath नाम की सुविधा का उपयोग किया गया, जिससे executable file dynamic library खोजने के लिए hard-coded path की जगह directories की एक श्रृंखला में खोज कर सके.
हमने क्या खोया
- Swift के OS में शामिल होने के बाद apps को अब Swift साथ में bundle करने की ज़रूरत नहीं रही, और Swift तथा Objective-C runtime साथ मिलने से performance सुधार संभव हुआ.
- लेकिन बाहरी Swift contributors को इस समस्या का सामना करना पड़ा कि नए API केवल नए OS में ही मौजूद होते हैं.
विकल्प
- डेवलपर्स के लिए बेहतर स्थिति देने के लिए Apple के पास कुछ उचित रास्ते हैं, लेकिन Apple इन्हें अपनाएगा या नहीं, यह स्पष्ट नहीं है.
निष्कर्ष
- Swift का OS में शामिल होना app developers के लिए शायद नुकसानदेह सौदा रहा हो, लेकिन Apple system libraries को Swift में लिखने का विकल्प छोड़ नहीं सकता था.
Swift से जुड़ी कोई नई बात नहीं
- Swift से जुड़ी कई समस्याएँ दरअसल OS के साथ आने वाली libraries का परिणाम हैं.
- Swift में हुए तकनीकी और सामाजिक, दोनों तरह के बदलावों ने इन समस्याओं को प्रभावित किया.
GN⁺ की राय
- Swift का OS का हिस्सा बनना डेवलपर्स पर अधिक प्रतिबंध लगाता है, लेकिन यह Apple के library distribution model का अनिवार्य परिणाम है.
- यह लेख Swift के OS में एकीकृत होने की प्रक्रिया में आए तकनीकी और परिचालन संबंधी challenges तथा उनके समाधानों की पड़ताल करके software development की जटिलता और library management के महत्व को रेखांकित करता है.
- Swift का OS integration app developers के लिए बड़े file size और compatibility समस्याएँ लाया, लेकिन Apple के लिए इसने system libraries को Swift में लिखने और update करने की क्षमता दी, जिससे पूरे system की consistency और security बनाए रखने में मदद मिली.
अभी कोई टिप्पणी नहीं है.