Crafting Interpreters: 15 महीनों में पूरी हुई 640-पेज की किताब

• वेब सीरियल खत्म होने के बाद भी Crafting Interpreters को असली किताब बनने के लिए 15 महीनों का अतिरिक्त काम लगा, और अंततः यह प्रिंट एडिशन, ईबुक और PDF के रूप में पूरी हुई
• Markdown और PNG के बंडल को किताब में बदलने के लिए Dart बिल्ड सिस्टम, InDesign XML import, JavaScript automation और typesetting validation तक नए सिरे से तैयार करने पड़े
• अंतिम परिणाम 8×10 इंच, 640 पेज, 2 लाख से अधिक शब्दों, 1,133 code snippets और सैकड़ों illustrations वाली किताब थी, जिसमें सामान्य web content की तुलना में कहीं अधिक कड़े layout constraints थे
• 5 महीने की पूरी समीक्षा, professional copyediting, 2 महीने की typesetting, 2 हफ्ते की indexing, proof copy की जांच और PDF comparison automation लगातार किए गए
• self-published technical book सिर्फ लिखने से पूरी नहीं होती; build, layout, validation और distribution automation ही किताब की quality और completeness तय करते हैं

---

web content पूरा होने के बाद भी बचा काम

• Crafting Interpreters का मुख्य text पहले ही पूरा हो चुका था, लेकिन उस समय output Markdown और PNG files को Python code से website में बदलने के रूप में था
• लक्ष्य शुरू से ही असली paper book था, और web पर आखिरी chapter डालने के बाद लगभग एक महीने का ब्रेक लिया गया
• लगभग 4 साल तक हर दिन लिखने के बाद author बहुत थक चुके थे, और 2020 की शुरुआत की परिस्थितियां भी काम जारी रखने के लिए मुश्किल समय थीं

Dart में दोबारा बनाया गया build system

• सबसे पहले readers द्वारा GitHub issues में report किए गए typos और errors सुधारे गए
• इसके बाद किताब का पूरा build system Dart में फिर से लिखा गया
  • पहली किताब का build script chapter-wise Markdown files को HTML में render करता था और code snippets insert करता था; यह एक single Python script था
  • Crafting Interpreters में दो complete interpreter codebases को 30 chapters में धीरे-धीरे बनाना था, इसलिए ज्यादा complex build की जरूरत थी
• नया build system किसी खास chapter या chapter के अंदर किसी खास point तक के interpreter code को programmatically output कर सकता था, उसे compile कर automated tests में चला सकता था
• author की skill level के हिसाब से Python-based tools maintain करना भारी था और speed भी धीमी थी
• Dart version ने desired HTML और syntax-highlighted code बिल्कुल सही generate किया, और पुराने Python version से 10 गुना तेज था
• Markdown processing पर ज्यादा control बाद में InDesign के लिए XML export में भी उपयोगी रहा

book design और trim size का फैसला

• book design, web development या game development की तरह पहले framework बनाने और फिर उसमें content डालने जैसा काम था
• InDesign में page margins और grid तय करने वाले master, और text व objects के font, style और color तय करने वाले styles set किए जाते हैं
• Crafting Interpreters में design difficulty बढ़ाने वाले कई elements थे
  • बहुत ज्यादा body text
  • किसी खास sentence, code या illustration को ठीक बगल में explain करने वाले लंबे asides
  • बहुत सारा code, और हर code snippet के बगल में result program में उसकी location का explanation
• horizontal width तय करते समय code की लंबी lines, aside area और मोटी किताब की inner margin—तीनों को साथ में ध्यान में रखना पड़ा
• author की bookshelf में मौजूद typical CS textbooks में 7.5-inch width आम थी, लेकिन code, asides और margins फिट करना मुश्किल था, इसलिए 8-inch width चुनी गई
• self-publishing में KDP और IngramSpark द्वारा support किए गए limited trim sizes ही इस्तेमाल करने थे, और 8-inch width में reasonable choice 8×10 inches थी
• vertical direction में text को classic 12pt baseline grid के अनुसार align किया गया

InDesign में ले जाने के लिए XML pipeline

• InDesign Markdown या author के build system को सीधे नहीं समझता था, इसलिए manual copy-paste practical नहीं था
• InDesign XML import और tags के हिसाब से styles automatically apply करने को support करता है
• हालांकि XML support में nested tags handling की limitations हैं, इसलिए HTML की तरह header के अंदर italic tag nest करने वाला तरीका ठीक से handle नहीं होता
• author अपने build system को सीधे control कर सकते थे, इसलिए उन्होंने InDesign को आसानी से accept होने वाले tags generate करने वाला custom XML exporter लिखा

InDesign JavaScript automation और limitations

• XML import InDesign की “story” बनाता है, यानी main text box के साथ चलता एक continuous text flow
• body text और code snippets main flow में जाते हैं, लेकिन aside और location marker को side में निकालना पड़ता था
• पिछली किताब में asides को manually काटकर नए text box में paste किया गया था, लेकिन इस किताब में code snippets 1,133 थे, इसलिए वही तरीका संभव नहीं था
• InDesign JavaScript scripting support करता है, लेकिन documentation और debugging environment बेहद कमजोर था
  • debugger नहीं
  • stack trace नहीं
  • सामान्य debug print नहीं
  • सिर्फ alert() इस्तेमाल किया जा सकता है, और call होने पर script रुक जाती है
• JavaScript script ने asides और location markers को ढूंढकर main text flow से निकाला और अलग text boxes बनाए
• positioning automation अंत तक पूरा नहीं हो पाया
  • InDesign के anchor feature और Object Style से placement करने की कोशिश की गई, लेकिन कुछ cases में आसपास के code snippets की borders गायब हो जाती थीं
  • अंततः कुछ location tags को manually position करना पड़ा

editing और copyediting

• पूरे text को शुरू से अंत तक दोबारा पढ़ने वाला editing pass किया गया
• हर chapter writing के दौरान पहले ही तीन drafts से गुजर चुका था, फिर भी पूरी किताब का flow देखने के लिए एक बार और review किया गया
• इस काम में 5 महीने लगे, और repeated jokes में से ज्यादातर को सुधारा गया
• इसके बाद professional copyeditor Kari Somerton को hire किया गया
• सामान्य editing workflow में Microsoft Word और Track Changes काफी इस्तेमाल होते हैं, लेकिन author plaintext और Git-based workflow बनाए रखना चाहते थे
• Kari Somerton ने Git और custom build system सीखा, फिर पूरी किताब review की और सैकड़ों errors खोजे
• पहले से चार drafts और readers के सैकड़ों issues होने के बावजूद professional copyeditor ने बहुत सारी problems पकड़ीं

640-page typesetting की constraints

• शब्दों को पर्याप्त polish करने के बाद InDesign में chapter-wise typesetting किया गया
• हर chapter का काम इस flow में repeat हुआ
  • नई InDesign file बनाना
  • XML export करना
  • XML को InDesign में import करना
  • JavaScript से asides और location markers निकालना
  • sidebar elements के anchors set करना
  • page end पर whitespace adjust करना
• पहले पांच steps हर chapter में करीब 30 मिनट में हो जाते थे, लेकिन आखिरी whitespace adjustment सबसे मुश्किल था
• book typesetting में कई vertical layout constraints होते हैं
  • illustrations को page के बीच में काटा नहीं जा सकता
  • aside एक page में रहे तो समझना आसान होता है
  • code snippets भी संभव हो तो page break से split न हों, यह बेहतर है
  • सिर्फ header का page के अंत में रह जाना avoid करना चाहिए
  • widows and orphans से बचना भी बेहतर है
• InDesign ऐसी स्थिति में content को next page पर push कर देता है, लेकिन इससे page के bottom में बड़ा white space बन जाता है
• illustrations और code snippets एक-दूसरे में उलझे bin-packing problem की तरह काम करते थे, और इसी वजह से पूरे chapters की typesetting में 2 महीने लगे
• whitespace कम करने के लिए code snippets को दो हिस्सों में बांटना, images के आसपास margins adjust करना या illustration height बदलना पड़ता था

illustrations, index और front/back matter

• illustrations के लिए print-friendly black-and-white pen drawings चुनी गईं, और पहली बार scan करते समय उन्हें 1200 DPI पर लिया गया
• high-resolution bitmap के रूप में export करना आसान था, लेकिन उन्हें page layout में place करना मुश्किल था
• body text “Figure 123 देखें” वाले तरीके का नहीं था, बल्कि sentence structure सीधे बगल की illustration की ओर इशारा करता था, इसलिए illustration को पास में ही रखना जरूरी था
• professional indexer hire किए बिना author ने खुद 2 हफ्ते तक सभी chapters फिर से देखते हुए index बनाया
• InDesign का index feature selected text को index entry बना सकता था और पूरा index generate कर सकता था, लेकिन entries जोड़ना अपने-आप में repetitive और boring काम था
• किताब के पीछे index रखा गया, और आगे title page, copyright page, dedication, acknowledgements और InDesign-generated table of contents शामिल किए गए

cover design

• author मानते थे कि technical book के cover की artistic quality शायद novel जितनी important न हो, लेकिन वे professor की position से sales force करने की स्थिति में नहीं थे, इसलिए cover पर काफी समय लगाया
• शुरुआत में वे अपने खींचे हुए photo को cover पर इस्तेमाल करना चाहते थे, लेकिन suitable photo नहीं मिला
• अंततः उन्होंने किताब की visual language यानी pen-and-ink illustrations इस्तेमाल करने का फैसला किया
• compilation process explain करने वाली mountain drawing को बड़ा और ज्यादा detailed बनाकर फिर से बनाया गया, और title letters भी नए hand-drawn feel के साथ बनाए गए
• title के लिए Acumin Pro Extra Condensed print करके उसे हाथ से trace किया गया ताकि imperfect feel आए, और 1950s के mimeographed scout manual जैसी color palette चुनी गई

proof copy और PDF change validation

• PDF को KDP पर upload किया गया और proof copy order की गई; एक हफ्ते बाद भारी box मिला
• physical book देखने के बाद ही project का scale data files नहीं, बल्कि physical object के रूप में महसूस हुआ
• typesetting process में manual work बहुत था, इसलिए proof copy को खुद पढ़ते हुए errors खोजे गए और sticky notes से mark किए गए
• InDesign files Git repository में रखी गईं, लेकिन वे विशाल opaque binary files थीं, इसलिए source code की तरह diff नहीं देखा जा सकता था
• InDesign कभी-कभी कोई actual change न दिखने पर भी file बदल देता है, इसलिए कौन-सा change हुआ यह verify करना मुश्किल था
• author ने Dart script लिखा, जो book PDF के सभी pages extract करके उन्हें एक बड़े PNG tile image में बदलता था
• हर commit पर PDF export करके tile images बनाए गए, और Photoshop action से दो images के अलग pixels पर लाल borders draw करके बदले हुए pages खोजे गए
• यह तरीका detailed changes सीधे नहीं बताता था, लेकिन कौन-से pages visually inspect करने हैं यह बताता था, और expected changes ही गए हैं या नहीं verify करने देता था

ebooks और launch

• print edition की proof corrections पूरी होने के बाद Kindle और EPUB ebooks भी बनाई गईं
• custom build system को modify किया गया ताकि EPUB द्वारा required पुराने XHTML, metadata और manifest export हो सकें
• कुछ command-line runs के बाद Kindle और EPUB ebooks तैयार किए गए, और कई readers में test करते हुए CSS adjust किया गया
• final files तैयार होने के बाद book website के first page को purchase links की ओर point करने के लिए update किया गया, और photos व responsive layout भी साफ किए गए
• store upload, site update और mailing list announcement तक पूरा होने के बाद किताब “सचमुच” complete state में पहुंची

आगे की योजना

• आखिरी chapter खत्म करने के बाद भी लोग next work या next book के topic के बारे में पूछते रहे
• author 6 साल तक एक project से जुड़े रहने के बाद फिलहाल नई किताब की planning नहीं करना चाहते थे
• pandemic के दौरान टाले गए काम भी बहुत थे, और कुछ समय तक क्या करना है यह तय किए बिना आराम करने की योजना थी
• music बनाना, fishing, friends और family के साथ समय बिताना, roguelike project पर काम करना जैसी संभावनाओं का जिक्र किया गया, लेकिन क्या करेंगे यह तुरंत तय नहीं किया गया
• उन्होंने कहा कि शायद किसी दिन फिर से कोई बड़ा project करने का मन हो सकता है, लेकिन वे फिर से एक project पर 6 साल खर्च नहीं करना चाहते

[GN⁺]

Hacker News की राय

• इस पेज पर किताब खरीदने का लिंक और मुफ़्त ऑनलाइन वर्ज़न का लिंक, दोनों हैं: https://craftinginterpreters.com/
  यह किताब निश्चित रूप से खरीदने लायक है। Nystrom ने फिजिकल बुक डिज़ाइन में जितनी मेहनत डाली है, वही प्रिंट पसंद करने वालों के लिए काफ़ी है, और हाथ से बनी इलस्ट्रेशन व बेहतरीन लेखन इसे 99% तकनीकी किताबों से बेहतर बनाते हैं

• अब तक पढ़ी गई तकनीकी किताबों में यह सबसे बेहतरीन में से एक थी। हर अध्याय में धीरे-धीरे विकसित होता कोड और अंत में चलने वाला प्रोग्राम बचा रहना एक कमाल की संरचना है, और लेखक ने इसे सच में पूरा किया, यह प्रशंसनीय है
  मैंने पहले कुछ ऐसा लिखने की कोशिश की थी, इसलिए tree-walk interpreter वाला हिस्सा सरसरी तौर पर देखा, और C-आधारित bytecode interpreter के साथ आगे बढ़ते हुए मैंने कहीं ज़्यादा सीखा

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

• 2017 में मैंने Crafting Interpreters को फ़ॉलो करना शुरू किया था, और किताब के पहले हिस्से पर काम करते हुए lox implementation को Java की जगह Scala में लिखा, जिससे tokenizer/lexer/parser/interpreter पूरी तरह रहस्यमय नहीं रहे
  पहले मुझे लगता था कि यह बस एक खास तरह के प्रोग्रामरों के लिए आरक्षित कोई दैवी क्षेत्र है, लेकिन इसका श्रेय Nystrom की शानदार लेखन शैली और विषय की गहरी समझ को जाता है। मैंने दूसरा interpreter Rust में लिखना शुरू किया था, लेकिन ज़िंदगी व्यस्त हो गई, इसलिए ज़्यादा आगे नहीं बढ़ पाया और पूरा भी नहीं कर सका। अब लगता है कि फिर से लौटने का समय आ गया है। यह पोस्ट कुछ साल पुरानी है, लेकिन मुझे पता ही नहीं था कि इसका फिजिकल एडिशन भी निकला है। भले ही यह मेरे सीखने के तरीके के लिए सबसे उपयुक्त न हो, फिर भी इसे अपने पास रखने और लेखक को समर्थन देने के लिए मैं एक कॉपी खरीदना चाहूँगा

  • शायद मैं भी ऐसा ही हूँ। वेब-आधारित पब्लिकेशन मेरे लिए बेहतर काम करते हैं, लेकिन Bob को सपोर्ट करने के लिए मैंने किताब भी खरीदी

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

• इस किताब के बारे में Bob की एक शानदार इंटरव्यू है, सुनने लायक: https://corecursive.com/032-bob-nystrom-on-building-an-inter...

• विडंबना यह है कि इस किताब को पूरा पढ़ने में मुझे भी 15 महीने लगे :). मैं लेखक की स्थिति से बहुत जुड़ाव महसूस करता हूँ। यह एक मेहनती और बेहतरीन लेखक की शानदार किताब है, और मुझे इससे इतना लगाव हो गया कि जो सीखा उसके आधार पर मैंने एक पेज भी बनाया: https://hexmos.com/compiler

• क्या लेखक ग्राफ़िक डिज़ाइनर से compiler engineer बने? यह हैरान करने वाला और प्रभावशाली है

  • किताब के प्रिंट-रेडी PDF बनाने के लिए InDesign, LaTeX से कहीं तेज़ लगता है। मैं भी InDesign ही चुनता। मैं खुद भी पूर्व डिज़ाइनर हूँ

• यह किताब मेरी शेल्फ़ पर रखी है। “Writing an interpreter in Go” के बाद यह अगली interpreter किताब होगी जिसे मैं पढ़ूँगा, और वह किताब लगभग 200 पन्नों की है, जो मुझे बहुत पसंद है

• मैंने अभी Java की जगह Rust में lexer पूरा किया है, और आगे का हिस्सा पढ़ने को लेकर उत्साहित हूँ। अभी तक यह शानदार किताब है