ฝีมือของช่างที่ดีดูได้จากเครื่องมือของเขา
— สุภาษิต
แม้ในปัจจุบัน โปรเจกต์ซอฟต์แวร์จำนวนมากก็ยังคงถูกดำเนินการเหมือนร้านเครื่องจักรในแง่ของเครื่องมือ ช่างฝีมือแต่ละคนมีชุดเครื่องมือส่วนตัวที่สะสมมาทั้งชีวิต เก็บล็อคและดูแลอย่างดี—ซึ่งเป็นหลักฐานที่เห็นได้ชัดของทักษะส่วนตัว เช่นเดียวกัน โปรแกรมเมอร์ก็มี editor เล็กๆ, sort, binary dump, utility จัดการพื้นที่ดิสก์ ฯลฯ ซ่อนไว้ในไฟล์ของตัวเอง
อย่างไรก็ตาม แนวทางแบบนี้ไม่เหมาะสมสำหรับโปรเจกต์ซอฟต์แวร์ ประการแรก ปัญหาหลักคือการสื่อสาร และเครื่องมือที่ปรับแต่งเฉพาะตัวกลับเป็นอุปสรรคมากกว่าช่วยในการสื่อสาร ประการที่สอง เทคโนโลยีเปลี่ยนไปเมื่อเราเปลี่ยนเครื่องจักรหรือภาษาในการทำงาน ดังนั้นอายุการใช้งานของเครื่องมือจึงสั้น สุดท้าย เห็นได้ชัดว่าการพัฒนาและบำรุงรักษาเครื่องมือเอนกประสงค์ร่วมกันนั้นมีประสิทธิภาพมากกว่ามาก
อย่างไรก็ตาม เครื่องมือเอนกประสงค์อย่างเดียวนั้นไม่เพียงพอ ทั้งความต้องการเฉพาะทางและความชอบส่วนตัวก็เป็นปัจจัยที่ทำให้ต้องมีเครื่องมือเฉพาะทางเช่นกัน ดังนั้นในการพูดถึงทีมพัฒนาซอฟต์แวร์ ผมจึงตั้งสมมติฐานว่าควรมี toolmaker หนึ่งคนต่อหนึ่งทีม คนนี้จะเชี่ยวชาญเครื่องมือทั่วไปทั้งหมดและสามารถสอนหัวหน้าของเขาในการใช้งานได้ นอกจากนี้เขายังสร้างเครื่องมือเฉพาะทางที่หัวหน้าต้องการอีกด้วย
ดังนั้นผู้จัดการโปรเจกต์จึงต้องกำหนดปรัชญาและจัดสรรทรัพยากรสำหรับการสร้างเครื่องมือทั่วไป ในขณะเดียวกันก็ต้องตระหนักถึงความจำเป็นของเครื่องมือเฉพาะทาง และไม่ควรขัดขวางทีมงานของเขาในการสร้างเครื่องมือของตัวเอง สิ่งล่อใจนี้แอบแฝงอยู่ บางครั้งเราอาจรู้สึกว่าถ้ารวบรวมช่างทำเครื่องมือที่กระจายอยู่ทั่วทุกทีมมารวมกันเป็นทีมเครื่องมือกลาง จะทำให้มีประสิทธิภาพมากขึ้น แต่ความจริงไม่ใช่เช่นนั้น
แล้วเครื่องมือที่ผู้จัดการต้องคิด วางแผน และจัดระเบียบมีอะไรบ้าง? อย่างแรกคือ computer facility สิ่งนี้ต้องการเครื่องจักร และต้องมีปรัชญาการจัดตารางเวลาที่เหมาะสม ต้องมี operating system และต้องกำหนดปรัชญาการบริการ ต้องมี language และต้องกำหนดนโยบายด้านภาษา จากนั้นก็มี utilities, debugging aids, test-case generators, และ text-processing system สำหรับจัดการเอกสาร มาดูทีละอย่างกันดีกว่า [1]
Target Machines (เครื่องจักรเป้าหมาย)
การสนับสนุนด้านเครื่องจักรสามารถแบ่งได้เป็น target machine และ vehicle machines target machine คือเครื่องที่เรากำลังเขียนซอฟต์แวร์ให้ และต้องทดสอบบนเครื่องนั้นในที่สุด ส่วน vehicle machines คือเครื่องที่ให้บริการต่างๆที่ใช้ในการสร้างระบบ ถ้าเรากำลังสร้าง operating system ใหม่ให้กับเครื่องเก่า เครื่องนั้นก็อาจทำหน้าที่ทั้งเป็น target และ vehicle ในเวลาเดียวกัน
แล้ว target facility ควรเป็นแบบไหน? ทีมที่สร้าง supervisor ใหม่หรือซอฟต์แวร์ที่เป็นหัวใจของระบบก็ต้องมีเครื่องของตัวเองอยู่แล้ว ระบบเหล่านี้จะต้องมี operator และ system programmer สักหนึ่งหรือสองคนที่คอยทำให้การสนับสนุนมาตรฐานบนเครื่องนั้นทันสมัยและใช้งานได้
ถ้าต้องการเครื่องแยกต่างหาก มันค่อนข้างเป็นอะไรที่แปลก—มันไม่จำเป็นต้องเร็ว แต่ต้องการหน่วยความจำหลักอย่างน้อยหนึ่งล้านไบต์, ดิสก์ออนไลน์หนึ่งร้อยล้านไบต์, และเทอร์มินัล เทอร์มินัลแบบ alphanumeric ก็พอ แต่ต้องเร็วกว่า 15 ตัวอักษรต่อวินาทีซึ่งเป็นลักษณะของเครื่องพิมพ์ดีดมาก หน่วยความจำขนาดใหญ่ช่วยเพิ่ม productivity ได้อย่างมาก เพราะช่วยให้การทำ overlaying และการปรับขนาดสามารถทำได้หลังจากการทดสอบการทำงาน
เครื่องที่ใช้ debug หรือซอฟต์แวร์ของมัน ก็ต้องถูก instrumented เช่นกัน เพื่อให้สามารถนับและวัดค่าพารามิเตอร์ต่างๆของโปรแกรมได้โดยอัตโนมัติระหว่างการ debug ตัวอย่างเช่น รูปแบบการใช้หน่วยความจำเป็นเครื่องมือวินิจฉัยที่ทรงพลังสำหรับสาเหตุของพฤติกรรมทางตรรกะที่ประหลาดหรือประสิทธิภาพที่ช้าอย่างไม่คาดคิด
การจัดตารางเวลา เมื่อ target machine เป็นเครื่องใหม่ เช่นเมื่อกำลังสร้าง operating system ตัวแรกให้กับมัน เวลาในการใช้เครื่องนั้นหายาก และการจัดตารางเวลาก็เป็นปัญหาใหญ่ ความต้องการใช้ target machine มีกราฟการเติบโตที่แปลกประหลาด ในการพัฒนา OS/360 เรามี simulator System/360 ที่ดีและ vehicle อื่นๆ จากประสบการณ์ที่ผ่านมา เราคาดการณ์ว่าต้องการใช้เวลา S/360 กี่ชั่วโมง และเริ่มจัดหาเครื่องรุ่นแรกๆจากการผลิตจากโรงงาน แต่พวกมันก็ไม่ได้ใช้งาน เดือนแล้วเดือนเล่า แล้วทันใดนั้นทั้ง 16 ระบบก็ถูกใช้งานเต็มที่ และปัญหากลายเป็นต้องปันส่วนเวลา การใช้งานมีลักษณะประมาณ Fig. 12.1 ทุกคนเริ่ม debug component แรกของตัวเองในเวลาเดียวกัน และหลังจากนั้นทีมส่วนใหญ่ก็ต้อง debug อะไรบางอย่างอยู่ตลอดเวลา
รูปที่ 12.1 การเติบโตของการใช้งาน target machine
เรารวบรวมเครื่องจักรและเทป library ทั้งหมดไว้ที่ศูนย์กลาง และจัดตั้งทีมห้องเครื่องมืออาชีพที่มีประสบการณ์มาดูแล เพื่อให้ใช้เวลา S/360 อันมีค่าได้สูงสุด เรารัน debug ทั้งหมดแบบ batch บนระบบใดก็ได้ที่ว่างและเหมาะสม เราพยายามให้ได้สี่รอบต่อวัน (รอบละสองชั่วโมงครึ่ง) และกำหนดให้รอบ turnaround สี่ชั่วโมง เครื่อง 1401 เสริมที่มีเทอร์มินัลถูกใช้เพื่อจัดตารางการรัน, ติดตามงานนับพันรายการ, และตรวจสอบ turnaround time
แต่การจัดระบบทั้งหมดนั้นเกินความจำเป็นไปมาก หลังจาก turnaround ช้า, การโทษกันไปมา, และความทุกข์ทรมานอื่นๆ เป็นเวลาหลายเดือน เราก็เปลี่ยนมาจัดสรรเวลาเครื่องเป็นบล็อกใหญ่ๆ ตัวอย่างเช่น ทีม sort ที่มีสิบห้าคนทั้งหมดจะได้รับระบบเป็นบล็อกสี่ถึงหกชั่วโมง เป็นหน้าที่ของพวกเขาที่จะจัดตารางเวลากันเอง ถ้ามันว่าง คนนอกก็ไม่มีสิทธิ์ใช้
ปรากฏว่านั่นเป็นวิธีจัดสรรและจัดตารางเวลาที่ดีกว่า แม้ว่าการใช้ประโยชน์จากเครื่องจักรอาจลดลงเล็กน้อย (และบ่อยครั้งก็ไม่ได้ลดลง) แต่ productivity เพิ่มขึ้นอย่างมาก สำหรับแต่ละคนในทีม การได้สิบรอบในบล็อกหกชั่วโมงให้ผลผลิตมากกว่าสิบรอบที่ห่างกันสามชั่วโมงมาก เพราะสมาธิที่ต่อเนื่องช่วยลดเวลาในการคิด หลังจาก sprint แบบนั้น ทีมมักต้องการเวลาหนึ่งหรือสองวันเพื่อจัดการเอกสารก่อนขอใช้บล็อกถัดไป บ่อยครั้งที่โปรแกรมเมอร์แค่สามคนก็สามารถแบ่งปันและจัดตารางเวลาย่อยในบล็อกเวลาได้อย่างมีประสิทธิภาพ นี่ดูเหมือนจะเป็นวิธีที่ดีที่สุดในการใช้ target machine เมื่อ debugging operating system ใหม่
ในทางปฏิบัติมันเป็นแบบนี้เสมอมา ถึงแม้ในทางทฤษฎีจะไม่เคยเป็น System debugging เป็นงานกะดึกมาโดยตลอด เหมือนกับดาราศาสตร์ เมื่อยี่สิบปีก่อน บนเครื่อง 701 ผมได้เริ่มเรียนรู้ถึงความไม่เป็นทางการที่มีประสิทธิภาพในช่วงก่อนรุ่งสาง ซึ่งเป็นเวลาที่หัวหน้าห้องเครื่องทั้งหมดหลับกันอยู่ที่บ้าน และผู้ควบคุมเครื่องก็ไม่ค่อยเคร่งครัดกับกฎระเบียบ เครื่องสามรุ่นผ่านไปแล้ว เทคโนโลยีเปลี่ยนไปหมดแล้ว operating system เกิดขึ้นมาแล้ว แต่วิธีการทำงานที่ชอบนี้ก็ยังไม่เปลี่ยน มันคงอยู่เพราะมันให้ productivity สูงที่สุด ถึงเวลาแล้วที่จะยอมรับ productivity ของมันและ embrace แนวปฏิบัติที่มีประสิทธิภาพนี้อย่างเปิดเผย
Vehicle Machines and Data Services (เครื่องจักรพาหนะและบริการข้อมูล)
Simulator ถ้า target computer เป็นเครื่องใหม่ เราจำเป็นต้องมี logical simulator สำหรับมัน สิ่งนี้ให้ debugging vehicle ตั้งแต่ก่อนที่ target ตัวจริงจะมีอยู่ด้วยซ้ำ ที่สำคัญไม่แพ้กันคือมันให้ access ไปยัง debugging vehicle ที่ dependable แม้เมื่อมี target machine พร้อมใช้งานแล้วก็ตาม
Dependable ไม่เหมือนกับ accurate Simulator จะต้องล้มเหลวในบางแง่มุมในการเป็น implementation ที่เที่ยงตรงและแม่นยำของสถาปัตยกรรมเครื่องใหม่ แต่มันจะเป็น implementation ที่ เหมือนเดิม ในแต่ละวัน ในขณะที่ hardware ใหม่จะไม่เป็นเช่นนั้น
ทุกวันนี้เราคุ้นเคยกับการที่ hardware คอมพิวเตอร์ทำงานได้ถูกต้องเกือบตลอดเวลา นอกจากว่า application programmer จะเห็นว่าระบบมีพฤติกรรมไม่สอดคล้องกันจากการรันหนึ่งไปสู่อีกรันหนึ่งที่เหมือนกัน เขาควรมองหา bug ใน code ของตัวเองมากกว่าในเครื่อง
อย่างไรก็ตาม ประสบการณ์นี้เป็น training ที่ไม่ดีสำหรับการเขียนซอฟต์แวร์สนับสนุนเครื่องใหม่ Hardware ที่สร้างในแล็บ, ก่อนการผลิต, หรือรุ่นแรกๆ จะ ไม่ ทำงานตามที่กำหนด, จะ ไม่ ทำงานอย่างน่าเชื่อถือ, และจะ ไม่ คงสภาพเดิมในแต่ละวัน เมื่อพบ bug ก็จะมีการเปลี่ยนแปลงทางวิศวกรรมในเครื่องทุกเครื่อง รวมถึงของทีมพัฒนา software ด้วย พื้นฐานที่เปลี่ยนแปลงนี้แย่พออยู่แล้ว Hardware failure ซึ่งมักเป็นแบบ intermittent นั้นแย่กว่า ความไม่แน่นอนนั้นแย่ที่สุด เพราะมันทำให้เราไม่อยากขุดคุ้ยหา bug ใน code อย่างจริงจัง—เพราะมันอาจจะไม่ได้อยู่ที่นั่นเลยก็ได้ ดังนั้น dependable simulator บน vehicle ที่เสถียรแล้วจึงยังคงมีประโยชน์ยาวนานกว่าที่คาดไว้มาก
Compiler และ assembler vehicles ด้วยเหตุผลเดียวกัน เราต้องการ compiler และ assembler ที่ทำงานบน dependable vehicles แต่ compile object code สำหรับ target system ซึ่งจากนั้นก็สามารถเริ่ม debug บน simulator ได้
ด้วยการเขียนโปรแกรมด้วย high-level language เราสามารถ debug ได้มากโดยการ compile และทดสอบ object code บน vehicle machine ก่อนที่จะเริ่มทดสอบ code บน target machine เลยด้วยซ้ำ สิ่งนี้ให้ประสิทธิภาพของการ execute โดยตรง แทนที่จะเป็นการ simulation ผนวกกับความน่าเชื่อถือของเครื่องที่เสถียร
Program library และ accounting การใช้ vehicle machine ที่ประสบความสำเร็จและสำคัญอย่างมากในความพยายามพัฒนา OS/360 คือการดูแล program libraries ระบบที่พัฒนาภายใต้การนำของ W. R. Crowley มีเครื่อง 7010 สองเครื่องเชื่อมต่อกัน แชร์ disk data bank ขนาดใหญ่ เครื่อง 7010 ยังมี S/360 assembler ด้วย code ทั้งหมดที่ทดสอบแล้วหรือกำลังถูกทดสอบถูกเก็บไว้ใน library นี้ ทั้ง source code และ assembled load modules Library นี้ถูกแบ่งออกเป็น sublibraries ที่มีกฎการเข้าถึงต่างกัน
อย่างแรก แต่ละกลุ่มหรือโปรแกรมเมอร์มีพื้นที่ที่เขาเก็บสำเนาโปรแกรมของตัวเอง, test cases, และ scaffolding ที่จำเป็นสำหรับการทดสอบ component ในพื้นที่ playpen นี้ไม่มีข้อจำกัดว่าเขาจะทำอะไรกับโปรแกรมของตัวเองได้บ้าง พวกมันเป็นของเขา
เมื่อมีคนมี component พร้อมสำหรับการ integration เข้าไปในชิ้นส่วนที่ใหญ่ขึ้น เขาจะส่งสำเนาให้กับผู้จัดการของระบบที่ใหญ่กว่านั้น ซึ่งจะใส่สำเนานี้ลงใน system integration sublibrary จากนั้นโปรแกรมเมอร์เดิมจะไม่สามารถเปลี่ยนแปลงมันได้ ยกเว้นโดยได้รับอนุญาตจาก integration manager เมื่อระบบเริ่มประกอบกัน ผู้จัดการ integration ก็จะดำเนินการทดสอบระบบทุกประเภท ระบุ bugs และรับ fix
ในบางครั้งระบบ version หนึ่งก็จะพร้อมสำหรับการใช้งานในวงกว้างขึ้น จากนั้นมันจะถูกเลื่อนไปยัง current version sublibrary สำเนานี้จะศักดิ์สิทธิ์ จะถูกแตะต้องก็ต่อเมื่อต้อง fix bug ที่ร้ายแรงเท่านั้น มันพร้อมใช้งานสำหรับ integration และการทดสอบ module version ใหม่ทั้งหมด program directory บนเครื่อง 7010 จะติดตามแต่ละ version ของแต่ละ module, สถานะ, ตำแหน่ง, และการเปลี่ยนแปลงของมัน
แนวคิดสองอย่างสำคัญที่นี่ อย่างแรกคือ control แนวคิดที่ว่าสำเนาโปรแกรมเป็นของผู้จัดการที่สามารถอนุญาตให้เปลี่ยนแปลงได้แต่เพียงผู้เดียว อย่างที่สองคือ formal separation และ progression จาก playpen สู่ integration สู่ release
ในความเห็นของผม นี่คือหนึ่งในสิ่งที่ทำได้ดีที่สุดในความพยายามพัฒนา OS/360 มันคือส่วนหนึ่งของ management technology ที่ดูเหมือนจะถูกพัฒนาขึ้นอย่างอิสระในโปรเจกต์ขนาดใหญ่หลายแห่งรวมถึงที่ Bell Labs, ICL, และ Cambridge University [2] มันใช้ได้กับทั้ง documentation และโปรแกรม มันเป็นเทคโนโลยีที่ขาดไม่ได้
Program tools เมื่อเทคนิค debugging ใหม่ๆปรากฏขึ้น เทคนิคเก่าก็ลดความสำคัญลงแต่ไม่หายไป ดังนั้นเรายังต้องการ dumps, source-file editors, snapshot dumps, แม้กระทั่ง traces
ในทำนองเดียวกัน เราต้องการ utilities ครบชุดสำหรับใส่ decks ลงดิสก์, ก็อปปี้เทป, พิมพ์ไฟล์, เปลี่ยน catalogs ถ้าเราจ้าง toolmaker ของโปรเจกต์ตั้งแต่ต้นกระบวนการ สิ่งเหล่านี้สามารถทำได้ครั้งเดียวและพร้อมเมื่อถึงเวลาที่ต้องการ
Documentation system ในบรรดาเครื่องมือทั้งหมด สิ่งที่ประหยัดแรงงานได้มากที่สุดน่าจะเป็นระบบ text-editing แบบคอมพิวเตอร์ที่ทำงานบน dependable vehicle เรามีระบบที่ใช้งานสะดวกมากซึ่งคิดค้นโดย J. W. Franklin ถ้าไม่มีมัน ผมคิดว่าคู่มือ OS/360 คงจะออกมาช้ากว่านี้มากและเข้าใจยากกว่านี้ มีคนที่เถียงว่าชั้นหนังสือ OS/360 สูงหกฟุตนั้นเป็น verbal diarrhea (การพูดมากเกินไป) ว่าความหนาแน่นที่มากเกินไปนั้นสร้างความไม่เข้าใจในรูปแบบใหม่ และก็มีความจริงในข้อนั้นอยู่บ้าง
แต่ผมตอบโต้ในสองทาง อย่างแรก เอกสาร OS/360 มีปริมาณมากมายมหาศาล แต่แผนการอ่านถูกจัดวางอย่างรอบคอบ ถ้าเราใช้มันอย่างเลือกสรรมากที่สุด เราก็สามารถไม่สนใจเนื้อหาส่วนใหญ่ได้เกือบตลอดเวลา เราต้องมองเอกสาร OS/360 เป็น library หรือสารานุกรม ไม่ใช่ชุดตำราบังคับอ่าน
อย่างที่สอง นี่ยังดีกว่าการมี documentation น้อยเกินไปอย่างรุนแรงซึ่งเป็นลักษณะของระบบซอฟต์แวร์ส่วนใหญ่ อย่างไรก็ตาม ผมจะยอมรับทันทีว่างานเขียนสามารถปรับปรุงได้อย่างมากในบางจุด และผลลัพธ์ของการเขียนที่ดีขึ้นจะทำให้ปริมาณลดลง บางส่วน (เช่น Concepts and Facilities ) ก็เขียนได้ดีมากในตอนนี้
Performance simulator ควรมีสักตัว สร้างมันแบบ outside-in ตามที่เราจะพูดถึงในบทต่อไป ใช้ top-down design เดียวกันสำหรับ performance simulator, logical simulator, และ product เริ่มมันตั้งแต่เนิ่นๆ ฟังมันเมื่อมันพูด
High-Level Language and Interactive Programming (ภาษา level สูงและการเขียนโปรแกรมแบบโต้ตอบ)
เครื่องมือที่สำคัญที่สุดสองอย่างสำหรับ system programming ในปัจจุบันคือสองอย่างที่ไม่ได้ถูกใช้ในการพัฒนา OS/360 เมื่อเกือบสิบปีก่อน พวกมันยังคงไม่ได้ถูกใช้อย่างแพร่หลาย แต่หลักฐานทั้งหมดชี้ไปที่พลังและความสามารถในการใช้งานของพวกมัน สองอย่างนั้นคือ (1) high-level language และ (2) interactive programming ผมเชื่อมั่นว่ามีเพียงความเฉื่อยและความเกียจคร้านเท่านั้นที่ขัดขวางการนำเครื่องมือเหล่านี้ไปใช้อย่างแพร่หลาย อุปสรรคทางเทคนิคไม่ใช่ข้อแก้ตัวที่สมเหตุสมผลอีกต่อไป
High-level language เหตุผลหลักในการใช้ high-level language คือ productivity และความเร็วในการ debug เราได้พูดถึง productivity ไปก่อนหน้านี้แล้ว (Chapter 8) ยังไม่มีหลักฐานเชิงตัวเลขมากนัก แต่ที่มีอยู่บ่งชี้ถึงการปรับปรุงแบบทวีคูณ ไม่ใช่แค่เปอร์เซ็นต์ที่เพิ่มขึ้นเล็กน้อย
การปรับปรุงด้าน debug มาจากความจริงที่ว่ามี bug น้อยลง และหาได้ง่ายขึ้น มีน้อยลงเพราะเราหลีกเลี่ยงการสัมผัสกับ error ทั้งระดับหนึ่ง ซึ่งเป็นระดับที่เราทำไม่เฉพาะ syntactic errors แต่ semantic errors ด้วย เช่นการใช้ registers ผิด bug หาได้ง่ายขึ้นเพราะ compiler diagnostics ช่วยค้นหาพวกมัน และที่สำคัญกว่าคือการแทรก debugging snapshots ทำได้ง่ายมาก
สำหรับผมแล้ว เหตุผลด้าน productivity และ debugging เหล่านี้ครอบงำมาก ผมไม่สามารถนึกภาพการสร้างระบบซอฟต์แวร์ที่ผมจะสร้างด้วย assembly language ได้ง่ายๆ
แล้วข้อโต้แย้งคลาสสิกต่อเครื่องมือแบบนี้ล่ะ? มีสามข้อ: มันไม่ให้ผมทำสิ่งที่ต้องการ, object code ใหญ่เกินไป, object code ช้าเกินไป
ในแง่ฟังก์ชัน ผมเชื่อว่าข้อโต้แย้งนี้ใช้ไม่ได้อีกแล้ว คำบอกเล่าทั้งหมดชี้ให้เห็นว่าเราสามารถทำสิ่งที่ต้องการได้ แต่ต้องใช้ความพยายามในการหาวิธี และบางครั้งอาจต้องใช้ artifices ที่ไม่สวยงาม [3] , [4]
ในแง่พื้นที่ optimizing compilers ตัวใหม่เริ่มน่าพอใจมาก และการปรับปรุงนี้จะดำเนินต่อไป
ในแง่ความเร็ว optimizing compilers ในตอนนี้สร้าง code ที่เร็วกว่า code ที่โปรแกรมเมอร์เขียนด้วยมือส่วนใหญ่ ยิ่งไปกว่านั้น เรามักจะแก้ปัญหาความเร็วได้โดยการแทนที่หนึ่งถึงห้าเปอร์เซ็นต์ของโปรแกรมที่ compiler สร้างขึ้นด้วย code ที่เขียนด้วยมือ หลังจากโปรแกรมของ compiler debug เสร็จสมบูรณ์แล้ว [5]
แล้วควรใช้ high-level language อะไรสำหรับ system programming? ผู้สมัครที่สมเหตุสมผลเพียงคนเดียวในปัจจุบันคือ PL/I [6] มันมีชุดฟังก์ชันที่ครบถ้วนมาก มันเข้ากันได้ดีกับ environment ของ operating system และมี compiler หลากหลายให้เลือก บางตัวเป็น interactive, บางตัวเร็ว, บางตัวมี diagnostic มาก, และบางตัวก็สร้าง code ที่ optimize สูง ผมเองพบว่ามันเร็วกว่าที่จะคิด algorithm ใน APL ก่อน แล้วจึงแปลมันเป็น PL/I เพื่อให้เข้ากับ environment ของระบบ
Interactive programming หนึ่งในเหตุผลของโปรเจกต์ Multics ของ MIT คือประโยชน์ของมันสำหรับการสร้างระบบซอฟต์แวร์ Multics (และตามมาด้วย IBM's TSS) แตกต่างในแนวคิดจากระบบ interactive computing อื่นๆ ในแง่มุมที่จำเป็นสำหรับ system programming: การแชร์และการป้องกันข้อมูลและโปรแกรมหลายระดับ, การจัดการ library ที่ครอบคลุม, และสิ่งอำนวยความสะดวกสำหรับการทำงานร่วมกันระหว่างผู้ใช้ terminal ผมเชื่อมั่นว่าระบบ interactive จะไม่มาแทนที่ระบบ batch สำหรับหลายๆแอปพลิเคชัน แต่ผมคิดว่าทีม Multics สร้างกรณีที่น่าเชื่อถือที่สุดในแอปพลิเคชัน system-programming
ยังไม่มีหลักฐานมากนักเกี่ยวกับประสิทธิผลที่แท้จริงของเครื่องมือที่ดูมีพลังเหล่านี้ แต่ มี การยอมรับอย่างกว้างขวางว่า debugging เป็นส่วนที่ยากและช้าที่สุดของ system programming และ turnaround ที่ช้าคือตัวหายนะของการ debug ดังนั้นตรรกะของ interactive programming จึงดูหลีกเลี่ยงไม่ได้ [7]
ยิ่งไปกว่านั้น เราได้ยินคำบอกเล่าที่ดีจากหลายคนที่สร้างระบบเล็กๆหรือส่วนหนึ่งของระบบด้วยวิธีนี้ ตัวเลขเดียวที่ผมเคยเห็นเกี่ยวกับผลกระทบต่อการเขียนโปรแกรมระบบขนาดใหญ่ถูก report โดย John Harr แห่ง Bell Labs ดังที่แสดงใน Fig. 12.2 ตัวเลขเหล่านี้มาจากการเขียน, assembly, และการ debug โปรแกรม โปรแกรมแรกส่วนใหญ่เป็น control program; อีกสามตัวเป็น language translators, editors, และอื่นๆ ข้อมูลของ Harr ชี้ให้เห็นว่า interactive facility อย่างน้อยก็ทำให้ productivity ใน system programming เพิ่มขึ้นเป็นสองเท่า [8]
รูปที่ 12.2 การเปรียบเทียบ productivity ระหว่าง batch และ conversational programming
การใช้งาน interactive tools อย่างมีประสิทธิภาพต้องทำงานด้วย high-level language เพราะ teletype และ typewriter terminals ไม่สามารถใช้ debug โดยการ dump หน่วยความจำได้ ด้วย high-level language source code สามารถแก้ไขได้ง่ายและ printout แบบเลือกเฉพาะก็ทำได้ง่าย เมื่อรวมกันแล้ว พวกมันกลายเป็นคู่เครื่องมืออันคมกริบอย่างแท้จริง