Sharp Tools
"ช่างฝีมือที่ดีเป็นที่รู้จักได้จากเครื่องมือของเขา" — สุภาษิต (PROVERB)
A. Pisano, "Lo Scultore," จาก Campanile di Santa Maria del Fiore, ฟลอเรนซ์, ประมาณปี ค.ศ. 1335
แม้ในปัจจุบัน โครงการเขียนโปรแกรมหลายโครงการยังคงดำเนินการเหมือนโรงกลึงในแง่ของเครื่องมือ ช่างเครื่องผู้ชำนาญแต่ละคนจะมีชุดเครื่องมือส่วนตัวที่สะสมมาตลอดชีวิต และถูกล็อกและเฝ้าไว้อย่างระมัดระวัง—ซึ่งเป็นหลักฐานที่มองเห็นได้ของทักษะส่วนบุคคล เช่นเดียวกัน นักเขียนโปรแกรมก็เก็บตัวแก้ไขข้อความ (editors) เล็กๆ รูทีนจัดเรียง (sorts) การดัมพ์ข้อมูลฐานสอง (binary dumps) โปรแกรมอรรถประโยชน์สำหรับพื้นที่ดิสก์ ฯลฯ ซ่อนไว้ในไฟล์ของตนเอง
อย่างไรก็ตาม แนวทางเช่นนี้เป็นเรื่องที่โง่เขลาสำหรับโครงการเขียนโปรแกรม ประการแรก ปัญหาที่สำคัญคือการสื่อสาร และเครื่องมือที่เป็นของส่วนตัวนั้นขัดขวางมากกว่าจะช่วยในการสื่อสาร ประการที่สอง เทคโนโลยีจะเปลี่ยนไปเมื่อเราเปลี่ยนเครื่องจักรหรือภาษาที่ใช้ทำงาน ดังนั้นอายุการใช้งานของเครื่องมือจึงสั้น ประการสุดท้าย ชัดเจนว่าการพัฒนาและการบำรุงรักษาเครื่องมือเขียนโปรแกรมอเนกประสงค์ร่วมกันนั้นมีประสิทธิภาพมากกว่ามาก
อย่างไรก็ตาม เครื่องมืออเนกประสงค์นั้นไม่เพียงพอ ทั้งความต้องการพิเศษและความชอบส่วนบุคคลต่างกำหนดความต้องการเครื่องมือเฉพาะทางด้วยเช่นกัน ดังนั้นในการอภิปรายเรื่องทีมเขียนโปรแกรม ผมจึงได้เสนอให้มีช่างทำเครื่องมือ (toolmaker) หนึ่งคนต่อทีม ชายคนนี้จะเชี่ยวชาญเครื่องมือส่วนกลางทั้งหมดและสามารถสอนหัวหน้าของเขาถึงวิธีการใช้งานได้ เขายังสร้างเครื่องมือเฉพาะทางที่หัวหน้าต้องการด้วย
ดังนั้น ผู้จัดการโครงการจำเป็นต้องสร้างปรัชญาและจัดสรรทรัพยากรสำหรับการสร้างเครื่องมือส่วนกลาง ในขณะเดียวกันเขาก็ต้องยอมรับความต้องการเครื่องมือเฉพาะทาง และไม่ขัดขวางทีมทำงานในการสร้างเครื่องมือของตนเอง สิ่งยั่วยวนนี้เป็นเรื่องที่อันตราย เรามักรู้สึกว่าหากรวบรวมช่างทำเครื่องมือที่กระจัดกระจายเหล่านั้นมาเสริมทีมเครื่องมือส่วนกลาง จะทำให้เกิดประสิทธิภาพมากขึ้น แต่มันไม่เป็นเช่นนั้น
อะไรคือเครื่องมือที่ผู้จัดการต้องวางปรัชญา วางแผน และจัดการ? ประการแรก คือสิ่งอำนวยความสะดวกด้านคอมพิวเตอร์ สิ่งนี้ต้องการเครื่องจักร และต้องมีการนำปรัชญาการจัดตารางเวลามาใช้ มันต้องการระบบปฏิบัติการ และต้องมีการกำหนดปรัชญาการบริการ มันต้องการภาษา และต้องมีนโยบายด้านภาษาที่ชัดเจน จากนั้นก็มีโปรแกรมอรรถประโยชน์ (utilities) เครื่องมือช่วยแก้ไขข้อผิดพลาด (debugging aids) ตัวสร้างกรณีทดสอบ และระบบประมวลผลข้อความเพื่อจัดการเอกสารประกอบ ให้เรามาดูสิ่งเหล่านี้ทีละอย่าง
Target Machines
การสนับสนุนด้านเครื่องจักรสามารถแบ่งออกเป็นเครื่องเป้าหมาย (target machine) และเครื่องพาหนะ (vehicle machines) เครื่องเป้าหมายคือเครื่องที่ซอฟต์แวร์ถูกเขียนขึ้นเพื่อใช้งาน และต้องถูกทดสอบบนเครื่องนั้นในท้ายที่สุด เครื่องพาหนะคือเครื่องที่ให้บริการต่างๆ ที่ใช้ในการสร้างระบบ หากเรากำลังสร้างระบบปฏิบัติการใหม่สำหรับเครื่องรุ่นเก่า เครื่องนั้นอาจทำหน้าที่เป็นทั้งเป้าหมายและพาหนะ
สิ่งอำนวยความสะดวกสำหรับเครื่องเป้าหมายแบบไหนที่จำเป็น?: ทีมที่สร้างตัวควบคุม (supervisors) ใหม่หรือซอฟต์แวร์ที่เป็นหัวใจของระบบอื่นๆ ย่อมต้องการเครื่องจักรเป็นของตัวเอง ระบบดังกล่าวต้องการเจ้าหน้าที่ควบคุมเครื่อง (operators) และนักเขียนโปรแกรมระบบสักคนหรือสองคนเพื่อคอยดูแลให้การสนับสนุนมาตรฐานบนเครื่องนั้นทันสมัยและพร้อมใช้งาน
หากจำเป็นต้องมีเครื่องแยกต่างหาก มันเป็นสิ่งที่ค่อนข้างพิเศษ—มันไม่จำเป็นต้องเร็ว แต่ต้องการหน่วยความจำหลักอย่างน้อยหนึ่งล้านไบต์ ดิสก์แบบออนไลน์หนึ่งร้อยล้านไบต์ และเทอร์มินัล ต้องการเพียงเทอร์มินัลแบบตัวอักษรและตัวเลข (alphanumeric terminals) เท่านั้น แต่มันต้องทำงานได้เร็วกว่า 15 ตัวอักษรต่อวินาทีซึ่งเป็นความเร็วของเครื่องพิมพ์ดีด หน่วยความจำขนาดใหญ่ช่วยเพิ่มผลิตภาพได้อย่างมาก โดยช่วยให้การวางซ้อน (overlaying) และการตัดแต่งขนาดทำได้หลังจากผ่านการทดสอบหน้าที่การทำงานแล้ว เครื่องสำหรับแก้ไขข้อผิดพลาด หรือซอฟต์แวร์ของมัน จำเป็นต้องมีเครื่องมือวัดผล (instrumented) เพื่อให้สามารถนับและวัดพารามิเตอร์ของโปรแกรมทุกประเภทได้โดยอัตโนมัติในระหว่างการแก้ไขข้อผิดพลาด รูปแบบการใช้หน่วยความจำ ตัวอย่างเช่น เป็นเครื่องมือวินิจฉัยที่มีประสิทธิภาพสำหรับสาเหตุของพฤติกรรมทางตรรกะที่แปลกประหลาดหรือประสิทธิภาพที่ช้าอย่างคาดไม่ถึง
การจัดตารางเวลา (Scheduling): เมื่อเครื่องเป้าหมายเป็นเครื่องรุ่นใหม่ เช่น เมื่อกำลังสร้างระบบปฏิบัติการแรกสำหรับเครื่องนั้น เวลาของเครื่องจักรจึงมีจำกัด และการจัดตารางเวลาเป็นปัญหาหลัก ความต้องการเวลาของเครื่องเป้าหมายมีกราฟการเติบโตที่แปลกประหลาด ในการพัฒนา OS/360 เรามีโปรแกรมจำลอง System/360 ที่ดีและพาหนะอื่นๆ จากประสบการณ์ก่อนหน้าเราคาดการณ์ว่าเราต้องการเวลาของ S/360 กี่ชั่วโมง และเริ่มจัดหาเครื่องรุ่นแรกๆ จากสายการผลิตของโรงงาน แต่พวกมันกลับจอดนิ่งอยู่เฉยๆ เดือนแล้วเดือนเล่า จากนั้นจู่ๆ ทั้ง 16 ระบบก็ถูกใช้งานจนเต็มพิกัด และการปันส่วนเวลาก็กลายเป็นปัญหา...
การใช้งานเครื่องจักรมีลักษณะคล้ายกับรูปที่ 12.1 ทุกคนเริ่มแก้ไขข้อผิดพลาดของส่วนประกอบแรกพร้อมๆ กัน และหลังจากนั้นสมาชิกส่วนใหญ่ในทีมก็กำลังแก้ไขข้อผิดพลาดของบางสิ่งบางอย่างอยู่ตลอดเวลา
รูปที่ 12.1 การเติบโตของการใช้งานเครื่องเป้าหมาย
เรารวบรวมเครื่องจักรและคลังเทปทั้งหมดไว้ที่ส่วนกลาง และจัดตั้งทีมห้องเครื่องมืออาชีพที่มีประสบการณ์เพื่อดูแลเครื่องเหล่านั้น เพื่อใช้เวลาของ S/360 ที่มีอยู่อย่างจำกัดให้คุ้มค่าที่สุด เราได้รันการแก้ไขข้อผิดพลาดทั้งหมดแบบแบตช์ (batch) บนระบบใดก็ตามที่ว่างและเหมาะสม เราพยายามให้มีการรันสี่ครั้งต่อวัน (เวลาดำเนินการรอบละสองชั่วโมงครึ่ง) และกำหนดให้เวลาดำเนินการต้องไม่เกินสี่ชั่วโมง มีการใช้เครื่อง 1401 สำรองพร้อมเทอร์มินัลเพื่อจัดตารางการรัน ติดตามงานนับพัน และตรวจสอบเวลาดำเนินการ
แต่การจัดองค์กรทั้งหมดนั้นดูจะมากเกินไป หลังจากผ่านไปไม่กี่เดือนกับเวลาดำเนินการที่ล่าช้า การกล่าวโทษกันไปมา และความทุกข์ระทมอื่นๆ เราจึงเปลี่ยนไปใช้วิธีจัดสรรเวลาเครื่องจักรเป็นช่วงเวลาใหญ่ๆ (substantial blocks) ตัวอย่างเช่น ทีมจัดเรียงข้อมูล (sort team) ทั้ง 15 คน จะได้รับระบบไปใช้งานในช่วงเวลา 4 ถึง 6 ชั่วโมง เป็นหน้าที่ของพวกเขาที่จะจัดตารางเวลากันเองบนเครื่องนั้น หากมันจอดนิ่งอยู่เฉยๆ คนภายนอกก็ไม่สามารถเข้ามาใช้งานได้
ปรากฏว่านั่นเป็นวิธีที่ดีกว่าในการจัดสรรและจัดตารางเวลา แม้ว่าการใช้ประโยชน์เครื่องจักรอาจจะต่ำลงเล็กน้อย (แต่มักจะไม่เป็นเช่นนั้น) แต่ผลิตภาพกลับพุ่งสูงขึ้น สำหรับแต่ละคนในทีมดังกล่าว การรัน 10 ครั้งในช่วงเวลา 6 ชั่วโมงต่อเนื่องกันนั้นมีผลิตภาพสูงกว่าการรัน 10 ครั้งที่ห่างกันช่วงละ 3 ชั่วโมงมาก เพราะการมีสมาธิอย่างต่อเนื่องช่วยลดเวลาในการขบคิด หลังจาก "การวิ่งระยะสั้น" เช่นนี้ ปกติทีมต้องการเวลาหนึ่งหรือสองวันเพื่อจัดการงานเอกสารให้ทันก่อนจะขอรับช่วงเวลาถัดไป บ่อยครั้งที่นักเขียนโปรแกรมเพียงสามคนก็สามารถแบ่งปันและจัดตารางเวลาย่อยในช่วงเวลานั้นร่วมกันได้อย่างมีประสิทธิภาพ
นี่ดูเหมือนจะเป็นวิธีที่ดีที่สุดในการใช้เครื่องเป้าหมายเมื่อต้องแก้ไขข้อผิดพลาดของระบบปฏิบัติการใหม่ มันเป็นเช่นนี้เสมอมาในทางปฏิบัติ แม้จะไม่เคยเป็นเช่นนั้นในทางทฤษฎีก็ตาม การแก้ไขข้อผิดพลาดของระบบเป็นอาชีพที่ต้องทำในช่วงกะดึก (graveyard-shift) เหมือนกับงานดาราศาสตร์ ยี่สิบปีก่อน ในเครื่อง 701 ผมได้รับการฝึกฝนให้รู้จักกับผลิตภาพจากความเป็นกันเองในช่วงเช้ามืด เมื่อบรรดาหัวหน้าห้องเครื่องนอนหลับปุ๋ยอยู่ที่บ้าน และเจ้าหน้าที่ควบคุมเครื่องก็ไม่เข้มงวดกับกฎระเบียบมากนัก เครื่องจักรผ่านไปสามยุคสมัย เทคโนโลยีเปลี่ยนไปอย่างสิ้นเชิง ระบบปฏิบัติการเกิดขึ้นมากมาย ทว่าวิธีการทำงานที่เป็นที่นิยมนี้ก็ยังไม่เปลี่ยนไป มันคงอยู่ได้เพราะมันให้ผลิตภาพสูงสุด ถึงเวลาแล้วที่จะยอมรับผลิตภาพของมันและรับเอาแนวทางปฏิบัติที่ได้ผลนี้มาใช้อย่างเปิดเผย
Vehicle Machines and Data Services
โปรแกรมจำลอง (Simulators): หากคอมพิวเตอร์เป้าหมายเป็นเครื่องรุ่นใหม่ เราจำเป็นต้องมีโปรแกรมจำลองเชิงตรรกะสำหรับมัน สิ่งนี้จะช่วยให้มีพาหนะสำหรับการแก้ไขข้อผิดพลาดก่อนที่เครื่องเป้าหมายจริงๆ จะมีอยู่ และที่สำคัญไม่แพ้กัน คือมันช่วยให้เราเข้าถึงพาหนะแก้ไขข้อผิดพลาดที่ "วางใจได้" แม้ว่าจะมีเครื่องเป้าหมายให้ใช้งานแล้วก็ตาม
"วางใจได้" (Dependable) ไม่ได้หมายความว่า "ถูกต้องแม่นยำ" (accurate) โปรแกรมจำลองจะมีความผิดพลาดในบางประการในการเลียนแบบสถาปัตยกรรมของเครื่องใหม่ได้อย่างซื่อสัตย์และแม่นยำ แต่มันจะเป็นการนำไปใช้งานที่ "เหมือนเดิม" ในทุกๆ วัน ในขณะที่ฮาร์ดแวร์ใหม่จะไม่เป็นเช่นนั้น ปัจจุบันเราคุ้นเคยกับการที่ฮาร์ดแวร์คอมพิวเตอร์ทำงานถูกต้องเกือบตลอดเวลา หากนักเขียนโปรแกรมประยุกต์ไม่พบว่าระบบทำงานไม่สอดคล้องกันในการรันซ้ำที่เหมือนเดิม เขามักจะได้รับคำแนะนำให้หาบั๊กในโค้ดของตนเองมากกว่าหาในเครื่องยนต์
อย่างไรก็ตาม ประสบการณ์นี้เป็น "การฝึกฝนที่แย่" สำหรับการเขียนโปรแกรมสนับสนุนเครื่องรุ่นใหม่ ฮาร์ดแวร์ที่สร้างในแล็บ รุ่นก่อนการผลิต หรือฮาร์ดแวร์รุ่นแรกๆ มักไม่ทำงานตามที่นิยามไว้ ทำงานไม่เสถียร และไม่มีการทำงานที่คงเดิมในแต่ละวัน เมื่อพบบั๊ก ก็จะมีการเปลี่ยนแปลงทางวิศวกรรมในเครื่องทุกเครื่อง รวมถึงเครื่องของกลุ่มเขียนโปรแกรมด้วย ฐานการทำงานที่เปลี่ยนไปมานี้แย่พออยู่แล้ว แต่ความล้มเหลวของฮาร์ดแวร์ที่มักจะเป็นแบบติดๆ ดับๆ นั้นแย่กว่า และความไม่แน่นอนคือสิ่งที่แย่ที่สุด เพราะมันทำลายแรงจูงใจในการขุดคุ้ยโค้ดเพื่อหาบั๊กอย่างขยันขันแข็ง—เพราะบั๊กนั้นอาจจะไม่ได้อยู่ที่นั่นเลยก็ได้ ดังนั้นโปรแกรมจำลองที่วางใจได้บนเครื่องพาหนะที่ผ่านการใช้งานมานานจึงยังคงมีประโยชน์นานกว่าที่ใครจะคาดคิด
เครื่องพาหนะสำหรับตัวคอมไพล์และตัวแอสเซมเบลอร์ (Compiler and assembler vehicles): ด้วยเหตุผลเดียวกัน เราต้องการตัวคอมไพล์และตัวแอสเซมเบลอร์ที่รันบนเครื่องพาหนะที่วางใจได้ แต่คอมไพล์โค้ดเป้าหมาย (object code) สำหรับระบบเป้าหมาย ซึ่งจากนั้นจะสามารถเริ่มแก้ไขข้อผิดพลาดบนโปรแกรมจำลองได้
ด้วยการเขียนโปรแกรมด้วยภาษาระดับสูง เราสามารถทำการแก้ไขข้อผิดพลาดส่วนใหญ่ได้โดยการคอมไพล์และทดสอบโค้ดบนเครื่องพาหนะก่อนที่จะเริ่มทดสอบโค้ดบนเครื่องเป้าหมายเลยด้วยซ้ำ สิ่งนี้ให้ประสิทธิภาพของการรันโดยตรง แทนที่จะเป็นการจำลอง และผสมผสานกับความน่าเชื่อถือของเครื่องที่เสถียร
คลังโปรแกรมและการบันทึกข้อมูล (Program libraries and accounting): การใช้งานเครื่องพาหนะที่ประสบความสำเร็จและสำคัญยิ่งในความพยายามพัฒนา OS/360 คือการบำรุงรักษาคลังโปรแกรม ระบบที่พัฒนาภายใต้การนำของ W. R. Crowley มีเครื่อง 7010 สองเครื่องเชื่อมต่อกัน โดยใช้คลังข้อมูลดิสก์ขนาดใหญ่ร่วมกัน เครื่อง 7010 ยังจัดเตรียมตัวแอสเซมเบลอร์ S/360 อีกด้วย โค้ดทั้งหมดที่ทดสอบแล้วหรืออยู่ระหว่างการทดสอบจะถูกเก็บไว้ในคลังนี้ ทั้งซอร์สโค้ด (source code) และโหลดโมดูล (load modules) ที่ผ่านการแอสเซมบลีแล้ว
ในความเป็นจริง คลังข้อมูลถูกแบ่งออกเป็นคลังย่อยที่มีกฎการเข้าถึงที่แตกต่างกัน:
ประการแรก แต่ละกลุ่มหรือนักเขียนโปรแกรมจะมีพื้นที่สำหรับเก็บสำเนาโปรแกรมของตนเอง กรณีทดสอบ และนั่งร้าน (scaffolding) ที่จำเป็นสำหรับการทดสอบส่วนประกอบ ในพื้นที่ "สนามเด็กเล่น" (playpen) นี้ไม่มีข้อจำกัดว่าแต่ละคนจะทำอะไรกับโปรแกรมของตนเองได้บ้าง เพราะมันเป็นของเขา
เมื่อพนักงานเตรียมส่วนประกอบของเขาพร้อมสำหรับการรวมเข้าเป็นส่วนที่ใหญ่ขึ้น เขาจะส่งสำเนาไปยังผู้จัดการของระบบขนาดใหญ่นั้น ซึ่งจะนำสำเนาไปใส่ไว้ในคลังย่อยสำหรับการรวมระบบ (system integration sublibrary) คราวนี้ นักเขียนโปรแกรมดั้งเดิมจะไม่สามารถแก้ไขมันได้ ยกเว้นจะได้รับอนุญาตจากผู้จัดการฝ่ายรวมระบบ เมื่อระบบเริ่มรวมเข้าด้วยกัน ผู้จัดการฝ่ายรวมระบบจะดำเนินการทดสอบระบบทุกประเภท ระบุบั๊กและดำเนินการแก้ไข
เป็นระยะๆ ที่ระบบเวอร์ชันหนึ่งจะพร้อมสำหรับการใช้งานที่กว้างขึ้น จากนั้นมันจะถูกเลื่อนระดับไปยังคลังย่อยเวอร์ชันปัจจุบัน (current version sublibrary) สำเนานี้ถือเป็นสิ่ง "ศักดิ์สิทธิ์" จะถูกแตะต้องเพื่อแก้ไขบั๊กที่ร้ายแรงเท่านั้น มันถูกจัดไว้ให้ใช้งานในการรวมระบบและการทดสอบโมดูลเวอร์ชันใหม่ทั้งหมด ไดเรกทอรีโปรแกรมบนเครื่อง 7010 จะคอยติดตามแต่ละเวอร์ชันของแต่ละโมดูล สถานะ ที่อยู่ และการเปลี่ยนแปลง
มีสองแนวคิดที่สำคัญที่นี่: ประการแรกคือการควบคุม แนวคิดที่ว่าสำเนาโปรแกรมเป็นของผู้จัดการซึ่งเป็นผู้เดียวที่สามารถอนุญาตให้มีการเปลี่ยนแปลงได้ ประการที่สองคือการแยกแยะอย่างเป็นทางการและการก้าวไปตามลำดับขั้น ตั้งแต่สนามเด็กเล่น ไปสู่การรวมระบบ และไปสู่การออกเวอร์ชัน ในความเห็นของผม นี่เป็นหนึ่งในสิ่งที่ทำได้ดีที่สุดในความพยายามของ OS/360 มันคือส่วนหนึ่งของเทคโนโลยีการบริหารจัดการที่ดูเหมือนว่าจะได้รับการพัฒนาขึ้นโดยอิสระในโครงการเขียนโปรแกรมขนาดใหญ่หลายโครงการ รวมถึงที่ Bell Labs, ICL และมหาวิทยาลัยเคมบริดจ์ มันสามารถนำมาปรับใช้กับงานเอกสารและตัวโปรแกรมได้ และเป็นเทคโนโลยีที่ขาดไม่ได้เลย
เครื่องมือโปรแกรม (Program tools): เมื่อเทคนิคการแก้ไขข้อผิดพลาดใหม่ๆ ปรากฏขึ้น เทคนิคเก่าๆ จะลดบทบาทลงแต่ไม่หายไป ดังนั้นเรายังคงต้องการการดัมพ์ข้อมูล (dumps), ตัวแก้ไขซอร์สไฟล์ (source-file editors), การดัมพ์แบบสแนปชอต (snapshot dumps) หรือแม้แต่การรันแบบติดตามผล (traces)
ในทำนองเดียวกัน เราต้องการชุดโปรแกรมอรรถประโยชน์ (utilities) ที่ครบถ้วนสำหรับการนำข้อมูลจากบัตรลงในดิสก์ การทำสำเนาเทป การพิมพ์ไฟล์ การเปลี่ยนแคตตาล็อก หากเรามอบหมายให้ช่างทำเครื่องมือของโครงการเริ่มงานตั้งแต่เนิ่นๆ สิ่งเหล่านี้ก็สามารถทำได้เพียงครั้งเดียวและพร้อมใช้งานเมื่อถึงเวลาที่ต้องการ
ระบบงานเอกสาร (Documentation system): ในบรรดาเครื่องมือทั้งหมด เครื่องมือที่ช่วยประหยัดแรงงานได้มากที่สุดน่าจะเป็นระบบแก้ไขข้อความด้วยคอมพิวเตอร์ที่ทำงานบนพาหนะที่วางใจได้ เรามีระบบที่สะดวกมากซึ่งคิดค้นโดย J. W. Franklin หากไม่มีมัน ผมคาดว่าคู่มือของ OS/360 คงจะล่าช้ากว่านี้มากและมีความลึกลับซับซ้อนยิ่งกว่าเดิม มีบางคนแย้งว่าคู่มือที่ยาวถึงหกฟุตของ OS/360 คืออาการ "ท้องเสียทางคำพูด" ความหนาที่มากเกินไปนั้นนำไปสู่ความไม่เข้าใจในรูปแบบใหม่ ซึ่งก็มีความจริงอยู่ในคำกล่าวนี้ แต่ผมขอโต้แย้งในสองประเด็น: ประการแรก เอกสารของ OS/360 นั้นมีจำนวนมหาศาลก็จริง แต่แผนการอ่านได้ถูกวางไว้อย่างระมัดระวัง หากเลือกใช้เฉพาะส่วน เราสามารถเพิกเฉยต่อความหนาส่วนใหญ่ได้เกือบตลอดเวลา เราต้องมองว่าเอกสารของ OS/360 เป็นเหมือนห้องสมุดหรือสารานุกรม ไม่ใช่ชุดตำราที่บังคับให้อ่านทั้งหมด ประการที่สอง วิธีนี้ยังดีกว่าการขาดแคลนเอกสารประกอบอย่างรุนแรงซึ่งเป็นลักษณะเด่นของระบบการเขียนโปรแกรมส่วนใหญ่ อย่างไรก็ตาม ผมเห็นด้วยว่างานเขียนในบางจุดสามารถปรับปรุงให้ดีขึ้นได้มาก และผลลัพธ์ของงานเขียนที่ดีขึ้นคือความหนาที่ลดลง
โปรแกรมจำลองประสิทธิภาพ (Performance simulator): ควรมีไว้สักอัน โดยสร้างมันจาก "ภายนอกสู่ภายใน" (outside-in) ดังที่เราจะพูดคุยกันในบทถัดไป ใช้การออกแบบจาก "บนลงล่าง" (top-down design) แบบเดียวกันทั้งสำหรับโปรแกรมจำลองประสิทธิภาพ โปรแกรมจำลองเชิงตรรกะ และตัวผลิตภัณฑ์เอง เริ่มสร้างมันตั้งแต่เนิ่นๆ และจงฟังเมื่อมันส่งเสียงเตือน
High-Level Language and Interactive Programming
เครื่องมือที่สำคัญที่สุดสองอย่างสำหรับการเขียนโปรแกรมระบบในปัจจุบันคือสิ่งที่ไม่ถูกนำมาใช้ในการพัฒนา OS/360 เมื่อเกือบสิบปีก่อน และแม้ในตอนนี้พวกมันก็ยังไม่ถูกใช้งานอย่างแพร่หลายนัก แต่หลักฐานทั้งหมดชี้ไปที่พลังและความเหมาะสมของพวกมัน ได้แก่ (1) ภาษาระดับสูง และ (2) การเขียนโปรแกรมแบบโต้ตอบ (interactive programming) ผมเชื่อมั่นว่ามีเพียงความเฉื่อยชาและความขี้เกียจเท่านั้นที่ขัดขวางการนำเครื่องมือเหล่านี้มาใช้อย่างเป็นสากล อุปสรรคทางเทคนิคไม่ใช่ข้ออ้างที่ฟังขึ้นอีกต่อไป
ภาษาระดับสูง (High-level language): เหตุผลหลักในการใช้ภาษาระดับสูงคือผลิตภาพและความเร็วในการแก้ไขข้อผิดพลาด เราได้พูดคุยเรื่องผลิตภาพไปก่อนหน้านี้แล้ว (บทที่ 8) แม้จะมีหลักฐานเชิงตัวเลขไม่มากนัก แต่ที่มีอยู่นั้นชี้ให้เห็นถึงการปรับปรุงที่ดีขึ้นหลายเท่าตัว ไม่ใช่แค่เพิ่มขึ้นเพียงไม่กี่เปอร์เซ็นต์
การปรับปรุงการแก้ไขข้อผิดพลาดมาจากข้อเท็จจริงที่ว่ามีบั๊กน้อยลง และพวกมันหาเจอได้ง่ายขึ้น ที่มีบั๊กน้อยลงเพราะเราหลีกเลี่ยงระดับความเสี่ยงต่อข้อผิดพลาดได้ทั้งระดับหนึ่ง ซึ่งเป็นระดับที่เราอาจทำผิดได้ทั้งทางไวยากรณ์และทางความหมาย เช่น การใช้รีจิสเตอร์ผิด ส่วนบั๊กหาเจอได้ง่ายขึ้นเพราะการวินิจฉัยของคอมไพเลอร์ช่วยหา และที่สำคัญกว่านั้นคือ การแทรกสแนปชอตสำหรับการแก้ไขข้อผิดพลาดทำได้ง่ายมาก สำหรับผม เหตุผลด้านผลิตภาพและการแก้ไขข้อผิดพลาดเหล่านี้มีน้ำหนักมหาศาล ผมแทบจินตนาการไม่ออกเลยว่าจะสร้างระบบการเขียนโปรแกรมด้วยภาษาแอสเซมบลีได้อย่างไร
แล้วข้อโต้แย้งแบบดั้งเดิมต่อเครื่องมือนี้ล่ะ? มีอยู่สามประการ:
- มันไม่ยอมให้ผมทำในสิ่งที่ต้องการ
-
โค้ดที่ได้ (
object code) มีขนาดใหญ่เกินไป - โค้ดที่ได้ทำงานช้าเกินไป
ในเรื่องของหน้าที่การทำงาน ผมเชื่อว่าข้อโต้แย้งนี้ใช้ไม่ได้อีกต่อไป คำยืนยันทั้งหมดระบุว่าเราสามารถทำในสิ่งที่ต้องการได้ แต่มันต้องใช้ความพยายามในการค้นหาวิธีการ และบางครั้งอาจต้องใช้กลเม็ดที่ไม่ค่อยสวยงามนัก ในเรื่องของพื้นที่ คอมไพเลอร์แบบปรับให้เหมาะสม (optimizing compilers) รุ่นใหม่ๆ เริ่มเป็นที่น่าพอใจมาก และการปรับปรุงนี้จะดำเนินต่อไป ในเรื่องของความเร็ว ปัจจุบันคอมไพเลอร์แบบปรับให้เหมาะสมสามารถสร้างโค้ดบางส่วนที่เร็วกว่าโค้ดที่นักเขียนโปรแกรมส่วนใหญ่เขียนด้วยมือ ยิ่งไปกว่านั้น เรามักจะแก้ปัญหาความเร็วได้โดยการเปลี่ยนโค้ดที่คอมไพเลอร์สร้างขึ้นเพียงหนึ่งถึงห้าเปอร์เซ็นต์ด้วยโค้ดที่เขียนด้วยมือ หลังจากที่โปรแกรมส่วนใหญ่นั้นได้รับการแก้ไขข้อผิดพลาดจนสมบูรณ์แล้ว
ควรใช้ภาษาระดับสูงใดสำหรับการเขียนโปรแกรมระบบ? ตัวเลือกเดียวที่สมเหตุสมผลในปัจจุบันคือ PL/I มันมีชุดฟังก์ชันที่ครบถ้วนมาก มันเข้ากันได้กับสภาพแวดล้อมของระบบปฏิบัติการ และมีคอมไพเลอร์ให้เลือกหลากหลาย ทั้งแบบโต้ตอบ แบบเร็ว แบบที่มีการวินิจฉัยดีเยี่ยม และแบบที่สร้างโค้ดที่มีการปรับให้เหมาะสมสูง ตัวผมเองพบว่าการคิดอัลกอริทึมใน APL นั้นเร็วกว่า จากนั้นผมจึงแปลสิ่งเหล่านั้นเป็น PL/I เพื่อให้เข้ากับสภาพแวดล้อมของระบบ
การเขียนโปรแกรมแบบโต้ตอบ (Interactive programming): หนึ่งในเหตุผลสนับสนุนโครงการ Multics ของ MIT คือประโยชน์ของมันในการสร้างระบบการเขียนโปรแกรม Multics (และต่อมาคือ TSS ของ IBM) แตกต่างในเชิงแนวคิดจากระบบคอมพิวเตอร์แบบโต้ตอบอื่นๆ ในแง่ที่จำเป็นสำหรับการเขียนโปรแกรมระบบพอดี: เช่น การแบ่งปันและการป้องกันข้อมูลและโปรแกรมในหลายระดับ การจัดการคลังโปรแกรมที่ครอบคลุม และสิ่งอำนวยความสะดวกสำหรับการทำงานร่วมกันระหว่างผู้ใช้เทอร์มินัล ผมเชื่อมั่นว่าระบบแบบโต้ตอบจะไม่มีวันเข้ามาแทนที่...
ระบบแบบแบตช์สำหรับหลายๆ แอปพลิเคชันได้ แต่ผมคิดว่าทีม Multics ได้สร้างข้อพิสูจน์ที่น่าเชื่อถือที่สุดในแอปพลิเคชันด้านการเขียนโปรแกรมระบบ
ขณะนี้ยังไม่มีหลักฐานมากนักเกี่ยวกับประสิทธิภาพที่แท้จริงของเครื่องมือที่ดูเหมือนจะมีพลังมหาศาลเช่นนี้ มีการยอมรับกันอย่างกว้างขวางว่าการแก้ไขข้อผิดพลาดเป็นส่วนที่ยากและช้าที่สุดของการเขียนโปรแกรมระบบ และเวลาดำเนินการ (turnaround) ที่ช้าคือศัตรูตัวฉกาจของการแก้ไขข้อผิดพลาด ดังนั้นตรรกะของการเขียนโปรแกรมแบบโต้ตอบจึงดูเหมือนจะเป็นสิ่งที่หลีกเลี่ยงไม่ได้
| โปรแกรม | ขนาด (บรรทัด) | แบบโต้ตอบ (C) หรือ แบตช์ (B) | คำสั่ง/คน-ปี |
|---|---|---|---|
| โค้ด ESS | 800,000 | B | 500-1000 |
| 7094 ESS | B | 2100-3400 | |
| 360 ESS Support | 32,000 | C | 8000 |
| 360 ESS Support | 8,300 | B | 4000 |
รูปที่ 12.2 การเปรียบเทียบผลิตภาพภายใต้การเขียนโปรแกรมแบบแบตช์และแบบโต้ตอบ
ยิ่งไปกว่านั้น เราได้รับฟังคำยืนยันที่ดีจากหลายคนที่สร้างระบบเล็กๆ หรือส่วนประกอบของระบบด้วยวิธีนี้ ตัวเลขเดียวที่ผมเคยเห็นเกี่ยวกับผลกระทบต่อการเขียนโปรแกรมระบบขนาดใหญ่คือรายงานจาก John Harr แห่ง Bell Labs ซึ่งแสดงอยู่ในรูปที่ 12.2 ตัวเลขเหล่านี้เป็นตัวเลขสำหรับการเขียน การประกอบ (assembling) และการแก้ไขข้อผิดพลาดของโปรแกรม โปรแกรมแรกส่วนใหญ่เป็นโปรแกรมควบคุม ส่วนอีกสามโปรแกรมเป็นตัวแปลภาษา ตัวแก้ไขข้อความ และอื่นๆ ข้อมูลของ Harr ชี้ให้เห็นว่าสิ่งอำนวยความสะดวกแบบโต้ตอบช่วยเพิ่มผลิตภาพในการเขียนโปรแกรมระบบได้อย่างน้อยสองเท่า
การใช้เครื่องมือแบบโต้ตอบส่วนใหญ่อย่างมีประสิทธิภาพต้องการให้งานทำในภาษาระดับสูง เพราะเทอร์มินัลแบบเทเลไทป์และเครื่องพิมพ์ดีดไม่สามารถใช้เพื่อแก้ไขข้อผิดพลาดโดยการดัมพ์หน่วยความจำได้ เมื่อใช้ภาษาระดับสูง ซอร์สโค้ดจะสามารถแก้ไขได้ง่ายและสามารถเลือกพิมพ์ข้อมูลออกมาดูได้ง่าย ทั้งสองสิ่งนี้เมื่อรวมกันจึงเป็นคู่เครื่องมือที่เฉียบคมอย่างแท้จริง