Pascal का उपयोग करने के कारण

 (castle-engine.io)
2 पॉइंट द्वारा GN⁺ 2023-07-10 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Object Pascal का लक्ष्य पढ़ने में आसान आधुनिक object-oriented language और native performance को साथ लाना है, और यह कई platforms पर maintainable applications बनाने का एक विकल्प है
  • strong typing, compile-time checks, और runtime checks की वजह से नाम की typo या type mismatch जैसी गलतियों को यूज़र तक पहुँचने से पहले पकड़ना आसान होता है
  • ज़रूरत पड़ने पर pointers, OS·CPU-विशिष्ट code, और assembly तक इस्तेमाल किए जा सकते हैं, लेकिन Castle Game Engine assembly के बिना भी तेज़ code बनाए रखने का विकल्प चुनता है
  • Windows, Linux, macOS, mobile, console, और web तक व्यापक targets को साधा जा सकता है, और Castle Game Engine में engine code और game code एक ही language में लिखे जाते हैं
  • FPC, Lazarus, Delphi, VS Code integration, और कई libraries के साथ Pascal ecosystem के भीतर भी एक practical development workflow बनाया जा सकता है

पढ़ने में आसान और type-safe Object Pascal

  • Object Pascal को आधुनिक, पढ़ने में आसान, और तेज़ type-safe cross-platform language माना जाता है
  • अगर आप दूसरी object-oriented languages जानते हैं, तो इसे अपेक्षाकृत आसानी से सीखा जा सकता है, और learning material के रूप में Modern Object Pascal Introduction for Programmers का उपयोग किया जा सकता है
  • इसमें वे सुविधाएँ हैं जिनकी आधुनिक object-oriented language से अपेक्षा की जाती है
    • classes
    • units
    • properties
    • generics
    • interfaces
    • reflection
    • closures
  • इसका syntax पढ़ने में आसान code पर केंद्रित है
  • type safety के लिए यह boolean, string, char, set, enum, range जैसे अलग types प्रदान करता है
    • सुरक्षित conversions, जैसे integer को float में assign करना, आसानी से संभाले जाते हैं
    • बाकी conversions को explicitly करना पड़ता है

compile और runtime में errors पकड़ने का तरीका

  • Object Pascal में compile-time checks पर ज़ोर दिया जाता है
  • data structures को reorganize करने जैसे refactoring के दौरान compiler उन जगहों को सामने ला सकता है जहाँ बदलाव ज़रूरी हैं
  • नाम की typo या type mismatch जैसी स्पष्ट गलतियाँ compile नहीं होतीं, इसलिए वे यूज़र तक नहीं पहुँचतीं
  • यह अतिरिक्त runtime checks भी देता है
    • array bounds checks
    • integer overflow checks
    • assertion
    • memory leak checks
  • runtime checks का उपयोग debug version में समस्याएँ पकड़ने के लिए किया जाता है, और performance-ज़रूरी release version में इन्हें बंद किया जा सकता है
  • CGE editor से compile करते समय debug / release modes अपने-आप set होते हैं, और “Run” menu में mode बदला जा सकता है
  • संबंधित दस्तावेज़ के लिए What are range and overflow checks (and errors) in Pascal और Detecting Memory Leaks देखे जा सकते हैं

native performance और ज़रूरत भर low-level control

  • Object Pascal native code में compile होता है, इसलिए बुनियादी execution performance पाना आसान होता है
  • सामान्य applications में low-level optimization तक नीचे जाने की ज़रूरत अक्सर नहीं पड़ती
  • लेकिन ज़रूरत होने पर मनचाहे स्तर तक low-level features इस्तेमाल किए जा सकते हैं
    • pointers का उपयोग
    • pointer arithmetic
    • OS·CPU-विशिष्ट code लिखना
    • assembly code जोड़ना
  • Castle Game Engine portability और code readability बढ़ाने के लिए बिल्कुल भी assembly code के बिना तेज़ execution का लक्ष्य रखता है
  • compilation भी काफ़ी तेज़ है; एक उदाहरण में नया project पहली बार खोलने पर desktop build में 2.5 सेकंड और Android build में 10.1 सेकंड लगे

कई platforms और Castle Game Engine की development approach

  • Object Pascal को कई तरह के platforms के लिए इस्तेमाल किया जा सकता है
    • desktop: Windows, Linux, macOS, Raspberry Pi, FreeBSD, संभवतः सभी Unix
    • mobile: Android, iOS
    • consoles: Nintendo Switch
    • web: WebAssembly, और pas2js का उपयोग कर JS
  • Castle Game Engine के supported platforms को Castle Game Engine platforms supported पर देखा जा सकता है
  • कुल उपलब्ध targets के लिए FPC target platforms और Delphi target platforms देखें
  • Castle Game Engine में engine code और game code एक ही language में लिखे जाते हैं
  • engine open source है, और ज़रूरत के मुताबिक CGE को fork करके बदला जा सकता है

libraries और development tools ecosystem

  • Pascal में कई क्षेत्रों के existing libraries और units उपलब्ध हैं
    • databases
    • XML, JSON
    • AI
    • blockchain
    • networking
  • जिन existing libraries में C API है, उनके साथ integration या linking आसानी से की जा सकती है
    • renderers
    • sound libraries
    • physics engines
  • Python libraries in Pascal भी इस्तेमाल की जा सकती हैं
  • मुख्य tools ecosystem इस प्रकार है
    • FPC: open source Free Pascal Compiler
    • Lazarus: FPC-आधारित open source Pascal IDE
    • Delphi: commercial Pascal compiler और IDE
    • VS Code: CGE और Pascal ecosystem के कई tools VS Code integration को स्पष्ट रूप से support करते हैं

संबंधित पढ़ाई

3 टिप्पणियां

 
gmong 2023-07-20

Delphi.. पुरानी यादें ताज़ा हो गईं। Borland, Delmadang..
 
xguru 2023-07-10

Windows डेवलपमेंट करने के दिनों में सच में लगता था कि Delphi के साथ Object Pascal सबसे बेहतरीन था।
 
GN⁺ 2023-07-10
Hacker News की राय

  • जिसने पहले Delphi इस्तेमाल किया हो, उसके लिए Lazarus पहले से जाना-पहचाना होने की संभावना काफी है। Lazarus लगभग एक open source reimplementation जैसा है, और Raspberry Pi जैसी ARM boards समेत लगभग हर जगह native रूप से चल और compile हो जाता है
    लेकिन library install करना झंझटभरा हो सकता है, इसलिए IDE, modules, और कुछ काफ़ी दिलचस्प add-ons की installation को automate करने के लिए FpcUp, और बाद में FpcUpDeluxe बनाया गया
    https://wiki.freepascal.org/fpcupdeluxe
    FpcUpDeluxe में शामिल free widgets से जल्दी में बनाया गया एक dashboard widget demo भी है
    https://ibb.co/9bchx7T
    FpcUpDeluxe Alpine Linux पर भी चलता है, और उसके लिए release page से musl version लेना होता है। इससे बहुत छोटे systems में भी dashboard डालने की संभावना खुलती है। कई platforms पर code native रूप से compile होता है और तेज़ चलता है, और किसी interpreter या web browser की ज़रूरत नहीं पड़ती

    • “free widgets” कहा गया है, तो क्या इसका मतलब paid widgets भी हैं? Qt5 के साथ तो इतने widgets आते हैं कि संभालना मुश्किल हो जाता है, इसलिए समझ नहीं आता कि Lazarus के default widgets सीमित हैं या नहीं
      जब मैंने आख़िरी बार Lazarus और Delphi इस्तेमाल किया था, तब Unicode मुश्किल था, और कुल मिलाकर ऐसा लगता था कि सब कुछ ASCII मानकर बनाया गया है
    • अगर आपको Lazarus, Qt, और 2D/3D CAD software में दिलचस्पी है, तो Delphi से दोबारा लिखी गई एक open source ship design और simulation project भी है
      [0] https://github.com/markmal/freeship-plus-in-lazarus
      [1] http://web.archive.org/web/20160128212152/http://hydronship.net/index.php?lang=en
      [2] https://sourceforge.net/projects/freeship

  • एक समय Delphi/Pascal मेरी मुख्य भाषा थी, और पिछले 10–20 सालों में मैं अपने लिए सही भाषा खोजता रहा हूँ। मैंने Haxe भी काफ़ी समय तक इस्तेमाल की, लेकिन आख़िर में ऐसा लगा कि मैं “वो macro से कर लो” वाले जाल में फँस गया। Macros से कुछ भी किया जा सकता है, लेकिन जब वे बहुत ज़्यादा हो जाते हैं, तो हर कोई अपनी अलग macro extension language में programming करने लगता है
    JavaScript में कुछ अच्छे सुधार आए हैं, और अभी भी और ज़रूरत है, लेकिन अब मैं उस तरफ़ का काम भी बहुत करता हूँ। कुछ साल पहले 8-bit AVR code लिखते समय मैंने फिर से FreePascal इस्तेमाल किया, और वह सच में बहुत मज़ेदार था। नए features आज़माने पर यह सचमुच एक modern language जैसा लगा, और छोटे target space के लिए code लिखते हुए standard library लगभग न इस्तेमाल करके ज़रूरी code खुद बनाना भी अच्छा लगा
    इससे FreePascal की कई सालों में जमा हुई backward-compatible namespace noise से बचना आसान हुआ, जैसे TList, TFPList, TFPGList, TFPGObjectList जैसी परतें। सबसे बड़ी कमी यह लगी कि compiler ने उन targets पर constant floating-point expressions की अनुमति नहीं दी जहाँ FPU या emulation नहीं था। अगर compile time पर calculation हो सकती है, तो यह संभव होना अच्छा रहता
    दूसरे environments इस्तेमाल करने के बाद अब function के बीच में variables define न कर पाना एक restriction जैसा लगता है, और subfunction-level scoping भी अच्छा होता। begin/end और {} का फ़र्क मुझे ज़्यादा परेशान नहीं करता। अब मुझे case-sensitive languages ज़्यादा पसंद हैं, और types पर character prefixes न लगाना बेहतर लगता है। शायद इसकी सबसे बड़ी वजह editors का विकास है। Syntax highlighting और realtime linting जानकारी को अलग परत में ले जाते हैं और text noise कम करते हैं
    अगर FreePascal की successor language एक fresh start के रूप में आए, तो शायद मैं काफ़ी उत्साहित हो जाऊँ। अच्छा होगा अगर एक नई standard library हो जो modern features को first-class citizen की तरह इस्तेमाल करे; retirement के बाद शायद मैं खुद एक बार इसे बनाने की कोशिश करूँ

    • begin/end और {} वास्तव में एक ही चीज़ नहीं हैं। {} local scope को define करता है, लेकिन begin/end ऐसा नहीं करता

  • 90s में मैंने कुछ साल तक काम के लिए Delphi इस्तेमाल किया था और मुझे वह पसंद भी था, लेकिन Borland और उसके बाद के owners जिस तरह product और language को बार-बार ग़लत दिशा में ले जाते रहे, उससे मैं थक गया। Anders Hejlsberg भी Borland छोड़कर Microsoft चले गए और उन्होंने C# बनाया, और मेरी नज़र में यह समय निवेश करने के लिए कहीं बेहतर language और architecture है

    • C# desktop apps को भरोसेमंद तरीके से deploy करना, Delphi/Lazarus द्वारा बनाए गए single exe की तुलना में, लगभग एक दुःस्वप्न जैसा है

  • आजकल resource constraints की वजह से मज़े के लिए Pascal इस्तेमाल कर रहा हूँ। पुराना Borland Turbo Pascal 3.00A CP/M पर चलता है, और editor, compiler, और library सब कुछ 64KB के अंदर देता है
    इंटरैक्टिव तरीके से इस्तेमाल करने के लिए यह काफ़ी तेज़ है, और low-level utilities, simple games, और तरह-तरह की hacking के लिए पर्याप्त code बना देता है। बड़े या आधुनिक environment में मैंने Pascal कभी इस्तेमाल नहीं किया, लेकिन हाल का अनुभव काफ़ी संतोषजनक रहा, इसलिए इसे ख़ारिज करने का इरादा नहीं है

    • Turbo Pascal और बाद का Delphi वही पल थे जब programming language पहली बार सच में समझ में आई। आख़िरकार मैं C और C++ की तरफ चला गया, लेकिन ज़्यादा expressive language में लौटने की इच्छा हमेशा रही
      मुझे अब तक पता ही नहीं था कि Pascal के modern implementations अभी भी मौजूद हैं, और शायद मुझे अपने पहले प्यार से फिर दोस्ती कर लेनी चाहिए
    • अगर अभी तक इस्तेमाल नहीं किया है, तो Free Pascal देखना अच्छा रहेगा। यह कई platforms को support करता है
      अगर CP/M चाहिए, तो site पर support status देख सकते हैं, और अगर support हो तो हैरानी नहीं होगी। इसका text UI IDE, Turbo Pascal से बहुत मिलता-जुलता है और बिजली की तरह तेज़ है। भाषा में Turbo Pascal की तुलना में कहीं ज़्यादा advanced features हैं, लेकिन अगर न चाहें तो उनका इस्तेमाल करना ज़रूरी नहीं
      पहले Windows पर हल्का-सा test किया था, तब generated binary भी C की तरह बहुत छोटी थी, और simple hello world program 50~60KB से कम था
    • आह, Pascal की nostalgia। TRS-80 Model III के दिनों में मैंने बड़ी मुश्किल से 80~100 डॉलर जोड़कर Pascal 80 package, New Classics version खरीदा था। वह लगभग शुरुआती IDE जैसा था, और उस समय के हिसाब से काफ़ी शानदार था। http://www.trs-80.org/pascal-80/
      याद है कि यह M-III BASIC development environment की तुलना में बहुत बड़ा improvement था, और 48KB RAM के अंदर भी मेरे बनाए games और utilities काफ़ी अच्छे से चलते थे। Pascal-80 codebase का क्या हुआ, यह जानने की उत्सुकता है। retro hardware के लिए modern tools से बेहतर तो नहीं होगा, और शायद काफ़ी कमज़ोर ही होगा। “Oh Pascal!” वही किताब थी जिससे मैंने यह language सीखी थी, और Pascal के commercial इस्तेमाल से कुछ साल पहले शायद बहुत ज़्यादा विकल्प भी नहीं थे

  • कुछ कारणों से सहमत होना मुश्किल है। Object Pascal कोई modern language नहीं है। 1998 में शायद थी, लेकिन उसके बाद इसमें बहुत ज़्यादा विकास नहीं हुआ, और आख़िरी बड़ा बदलाव भी generics था, जो लगभग बाकी सभी भाषाओं की तुलना में काफ़ी देर से आया
    FPC कोई ख़ास तेज़ code generate नहीं करता, और Object Pascal की object characteristics भी locality के लिए अनुकूल नहीं हैं। script languages से तेज़ है, लेकिन garbage collection वाली भाषाओं सहित आम तौर पर ज़्यादातर ahead-of-time compiled languages से धीमा रहता है
    दूसरी तरफ ecosystem शानदार है। अच्छी libraries और tools बहुत हैं, और सबसे उल्लेखनीय चीज़ Delphi clone Lazarus है। FPC या Delphi इस्तेमाल करने वाले लोग आम तौर पर language modernization जैसी बातों की ज़्यादा परवाह नहीं करते, वे बस काम पूरा करने पर ध्यान देते हैं। लेकिन नए developers को यह कितना आकर्षित करेगा, यह कहना मुश्किल है, इसलिए भविष्य कैसा होगा पता नहीं

    • Generics FPC में 17 साल पहले आए थे, इसलिए उसे हाल का बदलाव कहना ठीक नहीं होगा। हाल में जुड़े बड़े बदलावों में anonymous functions और function references, यानी closures, ज़्यादा उचित उदाहरण होंगे
      वास्तविक performance काफ़ी है, और bottleneck मिल जाए तो ज़रूरत के हिसाब से optimization भी किया जा सकता है। C++ की तुलना में “higher-level” classes इस्तेमाल करें तो थोड़ा ज़्यादा झंझट हो सकता है, लेकिन असंभव नहीं है
      अगर कम से कम मेहनत में base performance चाहिए, तो नया LLVM backend भी है। हालाँकि runtime library और FCL आदि सबको LLVM backend से build करना पड़ता है, इसलिए compiler को source से build करना होगा, लेकिन इसमें बस कुछ मिनट लगते हैं। बदले में compiler काफ़ी धीमा हो जाता है, और व्यक्तिगत रूप से मुझे नहीं लगता कि performance का फ़र्क इतना क़ीमती है
    • शायद आपने इसे बहुत कम आँका है। पहले ऐसे benchmarks भी रहे हैं जिनमें यह C++ जितना तेज़ था, और इसके मुख्य उपयोग local GUI apps में मैंने C# GUI apps सहित शायद ही कुछ इतना तुरंत responsive देखा हो
      इसलिए यह जानने की जिज्ञासा है कि कौन-सा benchmark था जिसने आपको लगा दिया कि यह असलियत से 50 गुना धीमा है
    • FPC के बारे में नहीं जानता, लेकिन Delphi 7 लगभग 10 साल पहले competitive programming में C++ के क़रीब था, और Java से लगभग 2~3 गुना तेज़ था
      यहाँ competitive programming से मतलब है ऐसे छोटे CPU-केंद्रित single-threaded algorithmic computations जिनकी समय-सीमा प्रति execution 1~3 सेकंड तक होती है। यह JIT के लिए प्रतिकूल environment होता है, और इसमें default compiler/runtime settings, बिना external libraries या tuning के काम किया जाता है। उस समय आम समझ यह थी कि C++/Pascal इस्तेमाल करो, या Java में करो और अगर “time limit exceeded” आ जाए तो 200~300 lines का solution C++ में फिर से लिखकर पास करवाओ
    • Pascal और C++ के बीच सबसे बड़ा अंतर developer experience है
      Pascal single-pass LL(1) compiler इस्तेमाल करता है, इसलिए millisecond स्तर की compilation संभव होती है। इससे Edit→Compile→Run एक सेकंड के अंदर पूरा हो जाने वाला REPL-जैसा अनुभव मिलता है। macro और धीमी compilation time वाले C/C++ की developer experience इससे बदतर थी, और कम-से-कम यही वजह थी कि मैंने C की जगह Pascal और C++ की जगह Delphi सीखा
    • मैं इस बात से बिल्कुल सहमत नहीं हूँ कि ecosystem शानदार है। मैंने लगभग 10 साल Pascal में काम किया, और modern libraries की कमी की वजह से बार-बार निराश होना पड़ा। आख़िरकार या तो मुझे अपने समाधान खुद बनाने पड़े, या पूरे ideas ही छोड़ने पड़े

  • समझ नहीं आता कि ऐसा क्यों करना चाहिए। पुरानी भाषाएँ legacy support की वजह से बनी रहनी चाहिए, लेकिन ऐसी modern features को पुरानी भाषा में ज़बरदस्ती ठूँसने का मतलब मुझे खास नहीं दिखता
    मैं Java बहुत इस्तेमाल करता हूँ, लेकिन सच कहूँ तो Java 8 के बाद की लगभग सभी features नहीं जोड़ी जानी चाहिए थीं। उदाहरण के लिए, Java में lambda काफ़ी हद तक एक patch जैसा लगता है
    अगर modern features चाहिएँ तो modern language इस्तेमाल करें। अगर Java ecosystem में रहना है तो Kotlin इस्तेमाल करें। Pascal को मैंने सचमुच दशकों से नहीं देखा, और आख़िरी बार 1980 के दशक में प्रोग्राम किया था, इसलिए मैं सिर्फ़ Java की बात कर रहा हूँ, लेकिन Pascal में ऐसी feature list जोड़ना हास्यास्पद लगता है

    • lambda patch जैसा है? क्या आपको सच में लगता है कि एक ही method वाली anonymous class बनाना बेहतर है?
    • Java में languages के बीच interoperability आसान है, इसलिए Kotlin जैसा विकल्प चुनना भी आसान है। Clojure के साथ भी यही बात है। लेकिन अगर आप C++ इस्तेमाल कर रहे हैं, तो किसी और चीज़ में आसानी से upgrade करने का रास्ता नहीं है
      फिर भी modern features जोड़ने की value है। आप नया project C++ में शुरू करने के बजाय Rust जैसी modern language चुन सकते हैं, लेकिन पहले से लिखी गई लाखों lines की C++ code को modern features से बेहतर बनाया जा सकता है। C++11 ने खेल ही बदल दिया था
    • तब programming languages कहीं ज़्यादा बार बदलनी पड़ेंगी। इस प्रक्रिया को धीमा करने के लिए फ़ायदा साबित कर चुकी नई features को जोड़ना और integrate करना तर्कसंगत लगता है
    • हाल तक Java में, उसके बेतुके रूप से बड़े ecosystem को छोड़ दें तो, 15 साल पहले के Delphi की तुलना में बहुत कम बेहतर बातें थीं। बेशक, वह ecosystem ही सब पर भारी पड़ता है
      Java language ने language features की बजाय libraries पर निर्भर रहने का जो फ़ैसला किया, उससे boilerplate code की बहुत बड़ी मात्रा पैदा हुई, और मुझे लगता है वह दिशा ग़लत थी। Python, Lisp, Haskell में जो किया जा सकता है, वह Java में भी किया जा सकता है, लेकिन परिभाषा के अनुसार brainf*ck में भी किया जा सकता है। असली Java solution की complexity अधिक feature-rich languages की तुलना में बढ़ जाती है, और अंत में या तो उन्हीं language features को थोड़े टूटे-फूटे ढंग से फिर से implement करना पड़ता है या उनकी जगह ढेर सारी dependencies खींचनी पड़ती हैं। दोनों ही मामलों में सीखने लायक API surface बस और बढ़ता है
    • प्रतिस्पर्धी JVM languages पिछले कुछ ही वर्षों में आई हैं। Scala एक dead end थी, Clojure लगभग एक fad थी, और Rhino/JS की महत्वाकांक्षा बहुत सीमित थी
      Java में हुए सुधारों की वजह से JVM प्रासंगिक बना रहा और DotNet को रोके रखा, और Microsoft के इतिहास को देखते हुए यह अच्छी बात थी

  • इस पर अक्सर ध्यान नहीं जाता, लेकिन Ada embedded ecosystem में static analysis, debugging, और target support की maturity के मामले में फ़ायदे हैं

    • मुझे हमेशा लगा कि Ada को कम आँका गया है। निजी तौर पर मैं memory safety, standard concurrency model, units/measurement types support, और separate compilation जैसी features को बहुत महत्व देता हूँ
      Ada का Pascal-जैसा syntax कुछ verbose लग सकता है, लेकिन पढ़ने में मुश्किल नहीं है। VHDL भी Ada syntax पर आधारित है, इसलिए जो लोग दोनों languages साथ इस्तेमाल करते हैं उनके लिए यह और आसान हो सकता है
      Swift भी इनमें से कुछ चीज़ें पूरी करता है, और closure, automatic reference counting, type inference जैसी सुविधाजनक features भी जोड़ता है। measurement types के बारे में पक्का नहीं हूँ, लेकिन वह implement किया जा सकने योग्य लगता है। हालाँकि अभी तक Swift जैसी कोई HDL दिखती नहीं है
    • सोच रहा हूँ कि क्या Ada अब Android और iOS targets को support करता है। जब मैंने आख़िरी बार देखा था, तब NDK के लिए build करने का कोई साफ़ तरीका नहीं दिख रहा था
    • macOS पर शुरू करने के लिए यह सबसे user-friendly विकल्प नहीं है

  • Pascal वास्तव में अच्छा है और performance भी ठीक-ठाक है। स्कूल में Basic के बाद मैंने दूसरी language यही सीखी थी
    समझ नहीं आता कि industry को 1990 के दशक के आख़िर और 2000 के शुरुआती वर्षों में Python, Ruby, Java, JavaScript की तरफ़ पीछे क्यों जाना पड़ा

    • मैंने हाल ही में इस विषय पर एक talk देखी: https://www.youtube.com/watch?v=Tml94je2edk
      उसमें बताया गया कि Python, Ruby, JS जैसी dynamically typed languages 1990 के दशक में क्यों लोकप्रिय हुईं: वेबसाइट बनाते समय वे तेज़ feedback loop देती थीं और IDE या compiler की ज़रूरत नहीं होती थी। उस समय IDE और compiler धीमे थे और कई बार मुफ़्त भी नहीं होते थे
      वैसे भी उस दौर में users 56k modem से कनेक्ट करते थे, इसलिए development time को performance gains के बदले देना बहुत फ़ायदेमंद सौदा नहीं था। उस talk में यह भी कई दिलचस्प बिंदु थे कि पिछले 10~20 वर्षों में development का तरीका कैसे बदला है, और रुझान फिर से static typing की ओर क्यों जा रहा है
    • कंप्यूटर तेज़ हो गए और memory भी बढ़ गई, तो उसके इस्तेमाल के लिए जगह बनानी ही थी ;-)
      साथ ही web browser एक लोकप्रिय programming platform बन गया और मुख्यतः JavaScript का इस्तेमाल हुआ। अब भी, browser वाले हिस्से के अलावा, web browser के अंदर एक पूरा operating system ठूँसने की कोशिश हो रही है, और Chrome काफ़ी करीब पहुँच चुका है

  • विश्वविद्यालय के पहले साल में मेरा पहला project Pascal में बना elevator simulator था, और उसमें text graphics का इस्तेमाल किया था। C-family languages की तुलना में Pascal में कुछ elegance थी, इसलिए उसे इस्तेमाल करना मज़ेदार था
    इसी वजह से मैं आजकल Nim का मज़ा ले रहा हूँ; जहाँ तक मुझे पता है, Nim पर Ada और Python के अलावा Pascal, Modula-3, Oberon, Delphi जैसी Wirth परिवार की languages का भी प्रभाव है

  • Pascal इतना भी बुरा नहीं है, और वास्तव में कुछ modern programming languages की तुलना में इसके अपने फ़ायदे हैं। बेशक यह परफ़ेक्ट नहीं है और इसकी कमियाँ भी हैं
    मैं कभी-कभी DOS programming के लिए Pascal और BASIC इस्तेमाल करता हूँ, और कम-से-कम उस काम के लिए Pascal ठीक लगता है। C भी DOS programming में इस्तेमाल होता है, लेकिन ख़ासकर real mode में वह इतना अच्छा नहीं लगता
    Linux programming के लिए मैं ज़्यादातर C को पसंद करता हूँ, लेकिन PostScript भी इस्तेमाल करता हूँ। मुझे लगता है कि C और PostScript, दोनों के कुछ modern languages पर अपने फ़ायदे हैं। Pascal का इस्तेमाल दूसरे programs में भी हो सकता है, और यहाँ तक कि TeX भी Pascal में लिखा गया था

    • जानना चाहूँगा कि आप PostScript का इस्तेमाल कहाँ करते हैं। print-संबंधित काम के अलावा इसे किसी और काम में इस्तेमाल करने वालों को देखना दिलचस्प लगता है