कैइलिक्स ने क्या किया गलत?

Question

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

Answer 1

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

यदि कोडगियर लिनक्स पर डेल्फी का एक और संस्करण करना चाहता है, तो उन्हें केवल Lazarus पर देखना चाहिए।

Answer 2

मुफ्त में उपकरण और सॉफ्टवेयर प्राप्त करने वाले लोगों के लिए 600 रुपये चार्ज करने का प्रयास करना एक बुद्धिमान निर्णय नहीं हो सकता है!

Answer 3

उन्हें कई अलग-अलग डिस्ट्रो किस्मों पर विश्वसनीय तैनाती बनाने में भी बहुत परेशानी थी।

Answer 4

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

Answer 5

क्या CodeGear बेहतर इस बार कर सकता है के लिए के रूप में:

• वहाँ संवाद में नियंत्रण बिछाने का एक और अधिक सार जिस तरह से होने की जरूरत है, नहीं पिक्सेल आधारित सामान VCL अब उपयोग करता है। यह पहले से ही उच्च डीपीआई सेटिंग्स या गैर-मानक फोंट के साथ विंडोज़ पर टूट जाता है, यह बहु-प्लेटफार्म कार्यक्रमों के लिए बहुत खराब होगा। उदाहरण के लिए sizer classes in wxWidgets, या जीटीके, जावा या क्यूटी में लेआउट क्लासेस/मैनेजर लें - वे सभी बदलते फोंट या नियंत्रण आकार के साथ बहुत बेहतर करते हैं। एक और लाभ के रूप में यह अनुवादित ग्रंथों के साथ पारदर्शी रूप से कम या लंबे नियंत्रण में काम करता है।

• लाइब्रेरी यूनिकोड केवल बनाएं। आदर्श रूप से विंडोज़ पर आंतरिक रूप से यूसीएस -16 का उपयोग करके एक विशेष स्ट्रिंग क्लास होगा, लेकिन लिनक्स और मैक ओएस एक्स के लिए यूटीएफ -8। एक प्रोग्राम मंच-मूल यूनिकोड एन्कोडिंग के साथ काम करने में सक्षम होना चाहिए, इसके लिए रूपांतरण नहीं होना चाहिए प्रत्येक फाइल सिस्टम का उपयोग या स्क्रीन आउटपुट। लेकिन शायद वे पहले से ही डेल्फी 2009 के लिए यूनिकोड स्ट्रिंग परिवर्तन

• जीयूआई उचित नज़र के लिए सभी प्लेटफार्मों पर देशी नियंत्रण का उपयोग करना चाहिए, और महसूस के साथ कि एक पर गेंद को गिरा दिया। यह विंडोज़ पर मानक नियंत्रण होगा, मैक पर कोको, और लिनक्स पर इसे आदर्श रूप से जीटीके या क्यूटी का उपयोग करना चाहिए, डेस्कटॉप पर गनोम या केडीई होने के आधार पर।

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

Answer 6

मैं समय (और अब भी) है, जो * nix पर पास्कल किया Kylix से पहले कम से मुफ्त पास्कल यूनिक्स RTL पर काम किया है, और हम मुट्ठी बीटा के पर से बारीकी से इसे देखा। तो कोई कह सकता है कि काइलिक्स के उदय और पतन पर मेरा अच्छा और अद्वितीय परिप्रेक्ष्य था।

एक मुख्य समस्या यह है कि यह सर्वर ऐप्स के उपयोग के लिए तैयार नहीं था, उस समय लिनक्स पर लोग मुख्य बात कर रहे थे, लेकिन आईएमएचओ जो विफलता की व्याख्या नहीं करता है।

हालांकि कई अन्य समस्याएं थीं (शराब, तैनाती, बहुत लिनक्स/x86- केंद्रित "अगले" * निक्स में बंदरगाह के लिए इतना कठिन है, बोर्लैंड इसे पर्याप्त धक्का नहीं दे रहा है), मुझे अभी भी लगता है कि किलिक्स विफल रहा है किलिक्स समस्याओं से प्रत्यक्ष परिणाम की तुलना में उस समय लिनक्स की पीड़ाओं के लिए एक और अधिक प्रमाण पत्र। जिनमें से कुछ (लंबी अवधि की बाइनरी एपीआई स्थिरता की तरह) अभी भी तय नहीं किए गए हैं।

फिर भी, यह, IMHO काम किया जाना चाहिए था, क्योंकि यह स्पष्ट रूप से आराम से आगे थी, और व्यावहारिक है, और अगर मांग वास्तव में वहाँ गया था, लोगों को तेज कर दिया होता (और कुछ है, हम अभी भी मासिक लोगों को एफपीसी सूचियों पर जो बड़े किलिक्स कोडबेस को परिवर्तित कर रहे हैं)।

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

Answer 7

क्या मैं Kylix और VCL के लिए वेब (Intraweb) के बारे में नफरत .... वे घटक है कि मानक घटकों की तरह लग रही है वह यह है कि

VCL ही काफी सामान्य (हैंडल के लिए छोड़कर) है ... तो मैं एक ही स्रोत कोड, एक ही पैस, डीएफएम, डीपीआर ... और एक कंपाइलर विकल्प चुनकर चुन सकता हूं कि कौन सा मंच बनाना है, या एक ही स्रोत फ़ाइलों के साथ प्रत्येक प्लेटफॉर्म के लिए अलग-अलग डीआरपी भी चुनें।

Answer 8

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

तो, आईएमओ, क्या है आवश्यक है:

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

ए) एक अच्छा दृश्य घटकों के ऑब्जेक्ट उन्मुख पदानुक्रम ... शायद वर्तमान पिक्सेल की तुलना में अधिक "प्रतिशत"/रिश्तेदार/वेक्टर-ग्राफिक योजना को भी गले लगाते हैं। (इस प्रकार स्क्रीन-रेज़ोल्यूशन असमानताओं की क्षतिपूर्ति।)

बी) ऑब्जेक्ट्स जो "जानती हैं" कैसे अपनी निहित वस्तुओं को प्रारंभ और मुक्त करने के लिए "(हालांकि ऑब्जेक्ट्स के पॉइंटर्स को छूट दी जाएगी, क्योंकि हम" साझा करने "की क्षमता चाहते हैं ऑब्जेक्ट्स), इसलिए कन्स्ट्रक्टरों की स्थापना को निहित वस्तुओं को मुक्त करने के लिए प्रारंभ करने और विनाशकों की स्थापना की आवश्यकता नहीं है। {आईई, सामान्य मामला अनुकूलित करें।}

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

डी) वस्तुओं को सबसे कम संभव स्तर पर, दूसरे छोर पर पुनर्निर्माण के लिए एक धारा में भेजने और भेजने/हटाने के लिए सक्षम होना चाहिए। {लागू करने में मुश्किल, शायद; लेकिन टर्बोविजन एपीआई ने इसे अपनी पंजीकरण योजना के साथ किया ... आरटीटीआई के साथ इसमें थोड़ा आसान होना चाहिए।}

ई) उपर्युक्त एडीटी में एक मिररिंग जेनेरिक इंटरफ़ेस वारिची भी होनी चाहिए, जैसे कि TStringList की तरह कुछ आपको देता है तारों की सूची जिनके मिलान करने वाली वस्तुओं की संपत्ति TIntergerObject प्रकार की वस्तुएं हैं।

एफ) कंटेनर प्रकार, जैसे स्टैक या स्ट्रिंगलिस्ट को उनके निहित प्रकार को भी जानना चाहिए; और क्या वे सजातीय हैं या नहीं।

छ) गैर दृश्य वस्तु पेड़ कि दाय है और सामान्यीकृत (शायद एक है कि "खाती" BNF और अपने आप में इनपुट तदनुसार ... एक विशाल परियोजना को पार्स करता है पर एक पार्सर वस्तु सबट्री।

मैं पता है कि यह एक लंबा आदेश है, और बहुत सी काम है। हालांकि भुगतान भी बहुत अधिक होगा। एक जेवीएम एक स्टैक ऑब्जेक्ट और एक पार्सर ऑब्जेक्ट हो सकता है जो स्रोत-कोड को उचित ऑब्जेक्ट्स में स्टैक पर धकेलने के लिए अनुवाद करता है ... एक फर्थ कंपाइलर/दुभाषिया को कई स्टैक्स और फर्थ पार्सर ऑब्जेक्ट के साथ उसी तरह कार्यान्वित किया जा सकता है। आप स्पष्ट रूप से देखते हैं कि यह कहां अग्रणी है: आधार पर एक बहुमुखी और सामान्यीकृत एडीटी लाइब्रेरी है और उस पर ढांचे का निर्माण आरएडी स्टूडियो का अगला पुनरावृत्ति एक में गिर सकता है न केवल एक प्रतिस्पर्धा बन गया इसके "किसी भी भाषा" विचार के लिए .NET के साथ टॉर, लेकिन बैकएंड पर एकाधिक आर्किटेक्चर के लिए भी। (हां, आकार और एंडियन मुद्दा है, लेकिन उच्च स्तरीय भाषाओं का विचार उन मुद्दों से प्रोग्रामर को हटाना है, जब तक कि वह विशेष रूप से उन पर ध्यान केंद्रित न कर रहे हों; उन मुद्दों को डेल्फी के बाइट, इंटीजर, लंबे समय तक आकार स्थिर नहीं है, क्योंकि यह वर्तमान में है [शायद मूल इंटेगर, नेटिव लोंगइंटर का उपयोग कर रहा है और जब मशीन-निर्भर प्रकार/आकार की आवश्यकता होती है] और फ़ाइलों के लिए टीस्ट्रीम-अवरोधक ऑब्जेक्ट्स को देकर डेल्फी-/आरएडी-मूल ऐप डेटा को संग्रहीत करने और पुनर्प्राप्त करने के लिए और उन लोगों से प्राप्त करना जब प्रारूप के लिए विशेष एंडियन की आवश्यकता होती है।)

Answer 9

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

डैनी थोर्प, डेल्फी/Kylix आर & डी, एक भावनात्मक लेख वापस लिखा था 2001 में:
Problem: Linux Libraries Can't Fail