มันทำได้ (2003)
(multicians.org)- ระหว่างการปรับโครงสร้าง ระบบไฟล์ Multics ที่ Honeywell Cambridge, André Bensoussan รับผิดชอบดูแล VTOC manager ซึ่งเป็นซับซิสเต็มหลัก ตั้งแต่การออกแบบไปจนถึงการทดสอบ
- โมดูลนี้ต้องย้ายข้อมูลคำอธิบายไฟล์ระหว่างดิสก์กับหน่วยความจำ รวมถึงจัดการบัฟเฟอร์พูลและพื้นที่ดิสก์ด้วย จึงแทบจะใกล้เคียงกับ ตัวจัดการหน่วยความจำเสมือนขนาดย่อม
- André ไม่ได้เขียนโค้ดตรงหน้าปลายทางเทอร์มินัลทันที แต่ขัดเกลาไดอะแกรมและโค้ดด้วยดินสอ พร้อมพยายามสร้าง การออกแบบที่สมมาตร ซึ่งยังคงเก็บข้อมูลสถานะไว้ได้
- หลังป้อนต้นฉบับสุดท้ายเข้าไป ปัญหาที่พบจากการคอมไพล์ครั้งแรกมีเพียง พิมพ์ผิด 3 จุด เท่านั้น และการรันหลัง bind เข้ากับระบบก็สำเร็จตั้งแต่ครั้งแรก
- บั๊กที่พบภายหลังมีเพียงจุดเดียว ซึ่งเกิดจาก Tom Van Vleck บอก ลำดับการเรียก ของขั้นตอนจัดการข้อผิดพลาดผิด ทำให้คุณภาพความสมบูรณ์ของโปรแกรมเองอยู่ในระดับสูงมาก
งานพัฒนา Multics VTOC manager
- André Bensoussan ทำงานเกี่ยวกับระบบปฏิบัติการ Multics ที่ Honeywell Cambridge ร่วมกับ Tom Van Vleck
- การเปลี่ยนแปลงครั้งใหญ่ของระบบไฟล์ต้องอาศัยซับซิสเต็มชื่อ VTOC manager
- ย้ายข้อมูลคำอธิบายไฟล์ระหว่างดิสก์กับหน่วยความจำ
- จัดการ บัฟเฟอร์พูล ในหน่วยความจำที่ใช้ร่วมกัน
- จัดการพื้นที่ดิสก์สำหรับข้อมูลไฟล์
- ด้วยบทบาทเช่นนี้ VTOC manager จึงต้องทำงานคล้าย ตัวจัดการหน่วยความจำเสมือน ขนาดเล็ก
- André รับหน้าที่ออกแบบ พัฒนา และทดสอบโมดูลนี้
โปรแกรมที่เสร็จสมบูรณ์ด้วยดินสอ
- André นั่งที่โต๊ะแล้ววาด ไดอะแกรม จำนวนมากก่อน
- เขาต้องการรูปแบบที่ดูดีและสมมาตร ขณะเดียวกันก็เก็บข้อมูลสถานะทั้งหมดไว้ได้
- ถึงขั้นที่คนรอบตัวกังวลว่าเขาจะเริ่มเขียนโค้ดช้าเกินไปเพราะกำหนดการ
- แม้แต่การเขียนโค้ดก็ทำด้วย ดินสอ ไม่ใช่ที่เทอร์มินัล
- เขาปฏิเสธความช่วยเหลือในการพิมพ์
- เขาเขียนบางส่วนใหม่ คัดลอก ลบ และแก้ไข จนกลายเป็นต้นฉบับสุดท้าย
- หลังจากป้อนต้นฉบับดินสอฉบับสุดท้ายทั้งหมดเข้าเทอร์มินัล การคอมไพล์ครั้งแรกไม่ผ่าน แต่เมื่อแก้ พิมพ์ผิด 3 จุด ก็สามารถคอมไพล์ได้สำเร็จ
- เมื่อ bind เข้ากับระบบแล้วรัน มันทำงานได้ตั้งแต่ครั้งแรก และหลังจากนั้น VTOC manager ก็ทำงานได้อย่างสมบูรณ์ต่อเนื่อง
- บั๊กเพียงจุดเดียวที่พบเกิดจาก Tom Van Vleck ตอบแบบคาดเดาโดยไม่ตรวจสอบ เมื่อ André ถามถึง ลำดับการเรียก ของขั้นตอนจัดการข้อผิดพลาด
- เมื่อเส้นทางข้อผิดพลาดนั้นถูกใช้งานครั้งแรก ระบบก็เกิด crash
- นอกเหนือจากนั้น โปรแกรมไม่มีปัญหาใดเลย
1 ความคิดเห็น
ความคิดเห็นใน Hacker News
ผมคิดว่าเหตุผลหลักที่เขาทำแบบนั้นได้คือ ข้อกำหนดถูกนิยามไว้อย่างชัดเจนมาก
ทุกวันนี้เหตุผลใหญ่ที่ซอฟต์แวร์มีบั๊กเยอะและช้า คือไม่มีใครรู้จริง ๆ ว่ากำลังสร้างอะไรอยู่ หรือแม้จะรู้ก็ยังเปลี่ยนไปเรื่อย ๆ เพราะ “Agile”
ถ้าให้ API ที่ชัดเจนและเกณฑ์ที่นิยามไว้อย่างดีแก่ developer ส่วนใหญ่ก็จะเขียนโค้ดที่ทำงานได้ดีมาก
ข้อกำหนดไม่ใช่การเอารายการกับ ticket ไปเรียงบน Kanban board แต่คือการเรียนรู้โดเมนของสิ่งที่จะสร้างจริง ๆ
เราอาจสร้างสิ่งที่อยู่ในขอบเขตที่ไม่เข้าใจได้ แต่ผลลัพธ์มักกลายเป็นขยะ และถ้ามองกระบวนการเขียนขยะนั้นเป็นการร่างเพื่อเรียนรู้โจทย์ของโดเมนกับแนวทางแก้ที่เป็นไปได้ ก็ถือว่าไม่เป็นไร
คุณภาพไม่มีทางลัด
หากคุณเป็น stakeholder ก็ควรเข้าถึงคนที่สร้างแอปพลิเคชันได้ และต้องตรวจสอบให้แน่ใจว่าพวกเขาเข้าใจโดเมน ซึ่งทำได้โดยไม่ต้องคอยไปรบกวนตลอดเวลา
ต้องระวังพวกขี้โม้ที่เอาแต่โยน buzzword ใส่
หากคุณเป็น designer หรือ programmer ต้องแน่ใจว่า stakeholder และผู้เชี่ยวชาญโดเมนมีส่วนร่วมอย่างจริงจังและใส่ใจ ไม่อย่างนั้นการดึงข้อกำหนดและความเข้าใจออกมาจะยากเหมือนถอนฟัน
stakeholder บางคนอาจไม่ได้อยากแก้ปัญหาด้วยซ้ำ อาจอยากไปคนละทิศทางโดยสิ้นเชิง หรืออาจงอนด้วยเหตุผลทางการเมืองก็ได้ ไม่มีอะไรทำให้โปรเจกต์จมได้เท่า stakeholder ที่ขี้เกียจหรือไม่สนใจ
stakeholder ไม่รู้ว่าตัวเองต้องการอะไร แต่ก็ยังขอฟีเจอร์เพิ่มหรือการเปลี่ยนแปลงครั้งใหญ่แบบสุ่ม ๆ
ต้องใส่ exception handling จำนวนมากเพราะฝืนใช้เครื่องมือนี้ทำสิ่งที่ไม่ควรใช้มันทำ
designer มักสร้าง design ที่ขัดกับฟังก์ชันที่จำเป็น พฤติกรรมของระบบเดิม และความต้องการของ stakeholder ส่วนทีมที่พัฒนาแต่ละส่วนของระบบก็ทำงานอยู่ใน silo โดยสื่อสารกันไม่ดี
กระบวนการ “Agile” ที่ออกแบบผิดพยายามยัดทุกอย่างให้เสร็จภายในช่วงเวลาหนึ่งตามการประเมินคะแนนที่น่าสงสัย
สุดท้ายปัญหาเหล่านี้ทำให้ระบบไม่ทำงานตามที่ตั้งใจ หรือกลายเป็นกองบั๊ก
ถ้าสร้างสภาพแวดล้อมที่ข้อกำหนดชัดเจนและไม่เปลี่ยน สมาชิกโปรเจกต์สื่อสารกันดี และควบคุมกระบวนการได้เต็มที่ ทุกอย่างก็จะออกมาดี กรณีในต้นฉบับก็ดูเป็นแบบนั้น
ผมทำงานกับบริษัทใหญ่เป็นหลัก งานที่เข้ามา 90–99% เป็นกรณีทั่วไป
แต่ก็มีกรณีพิเศษระดับยูนิคอร์นอยู่มากมาย ที่เกิดขึ้นสักครั้งใน 3 ปี แถมประมาณว่าต้องเกิดจันทรุปราคาและสุริยุปราคาพร้อมกัน แล้วมีแม่มดสวดคาถาในป่าพอดี
พอต้อง implement กรณีเหล่านี้ลงในโค้ดแทนที่จะจัดการด้วยมือ ก็เกิดบั๊ก และมีโค้ดให้ review กับ maintain มากขึ้นมาก
เรื่อง maintenance อย่าเพิ่งเริ่มพูดเลย เป็นแผลเจ็บอยู่
ข้อกำหนดเปลี่ยนเสมอ มันเหมือนพลังธรรมชาติ และไม่มีโลกที่ทุกคนรู้ตั้งแต่แรกว่าจะสร้างอะไร ได้ API ที่ระบุครบถ้วน แล้วเข้าไปนั่งในถ้ำเพื่อ implement อย่างเดียว
ความจริงไม่เคยเป็นแบบนั้น และถ้าต้องการเงื่อนไขแบบนั้น software engineering ก็อาจไม่ใช่อาชีพที่เหมาะ
ถ้าไม่มีผู้ใช้ ซอฟต์แวร์ของผมคงสมบูรณ์แบบ ;)
ผมเคยทำงานกับคนที่ลี้ภัยมาจากสหภาพโซเวียต เขาบอกว่าเหตุผลที่ โปรแกรมเมอร์โซเวียต เก่งมาก เป็นเพราะการเข้าถึงคอมพิวเตอร์ถูกจำกัดอย่างหนัก
ถ้าต้องเขียนโปรแกรมด้วยดินสอกับกระดาษ คุณก็อยากให้มันทำงานได้ตั้งแต่รันครั้งแรก
บังเอิญว่าตอนนั้นพวกเราทำงานที่ Honeywell
ถ้าอย่างนั้นนี่เป็นวิธีสอนที่ดี หรือเป็นตัวกรองที่ดีในการคัดคนที่มีแรงจูงใจน้อยกว่าออกกันแน่?
ที่โรงเรียนเราใช้คอมพิวเตอร์ในชั้นเรียนไม่ได้ เลยคุ้นเคยกับการเขียนโปรแกรมบนกระดาษ และถึงขั้น debug บนกระดาษด้วย
พอกลับถึงบ้าน ผมก็พิมพ์เข้าไปแล้วลองรัน และสงสัยว่าจะจำลอง เกร็ดเรื่อง Multics ที่เคยอ่านได้ไหม
compile ครั้งแรกล้มเหลว แต่หลังจากแก้ชื่อตัวแปรหนึ่งตัว มันก็ทำงานได้สมบูรณ์แบบ
จำได้ว่าอยู่หลายปีที่ในลูป edit→compile→printout นั้น listing printout ดีกว่า terminal มาก เพราะการดูโค้ด เลื่อนตำแหน่ง และแก้ไขโค้ดอย่างมีประสิทธิภาพทำได้ยาก
สุดท้ายมันดีขึ้นเมื่อมี visual editor ที่ดีกว่า terminal ที่ใหญ่ขึ้น และการ compile กับรันที่เร็วขึ้น
ถ้าเปรียบเทียบก็เหมือนอาวุธปืนยุคแรก ๆ ที่ช่วงเปลี่ยนผ่านจากธนูยาวยังไม่มีประสิทธิภาพ เพราะดินปืนเปียกง่าย กลไกจุดไฟแบบ flintlock ไม่นิ่ง และต้องยัดทุกอย่างลงปากกระบอก
ในเธรด HN ก่อนหน้าของบทความนี้ มีคอมเมนต์ดี ๆ จากบัญชี jrd259 ที่เคยทำงานกับ André: https://news.ycombinator.com/item?id=18415231
เป็นเรื่องเกี่ยวกับความสำคัญของ โต๊ะทำงานกว้าง ๆ และพื้นที่ทำงานส่วนตัวที่ไม่มีการแจ้งเตือน
นึกถึงสองครั้งในชีวิตที่ผมเคยเขียนโปรแกรมบนกระดาษ
ครั้งแรกน่าจะตอนอายุราว 10–12 ปี ผมไปบ้านปู่ย่าตายายซึ่งไม่มีทั้งคอมพิวเตอร์และสมาร์ตโฟน แต่มีเครื่องพิมพ์ดีดแบบกลไกที่สลับพิมพ์สีดำกับสีแดงด้วยสวิตช์ได้
ตอนนั้นงานอดิเรกหลักของผมคือ Turbo Pascal เลยใช้เครื่องพิมพ์ดีดเขียนโปรแกรม Pascal ที่ตั้งใจว่าจะเอากลับไปพิมพ์ลง PC ที่บ้านแล้วรันทีหลัง
เพราะอยู่บ้านปู่ย่าตายายหนึ่งสัปดาห์ จึงมีเวลาพอให้คิดอย่างถี่ถ้วน ดีบักด้วยมือ และพิมพ์ส่วนที่ผิดใหม่
ครั้งที่สองเกี่ยวกับภาษาโปรแกรมเชิงพิสดารที่ผมสร้างเองชื่อ Ziim(https://esolangs.org/wiki/Ziim) และฟังก์ชันบวกเลขฐานสองในหน้านั้น
ฟังก์ชันนั้นใหญ่และซับซ้อนมาก และมีบั๊ก ผมรู้ว่ามีบั๊กเพราะลองรันในอินเทอร์พรีเตอร์แล้ว แต่ไม่รู้ว่าปัญหาอยู่ตรงไหนหรือจะแก้อย่างไร
พอดีมีโอกาสต้องนั่งรถบัสทางไกลประมาณ 6 ชั่วโมง ซึ่งเป็นโอกาสที่สมบูรณ์แบบสำหรับการดีบัก
ผมคัดลอกฟังก์ชันบวกของ Ziim ลงบนกระดาษกริดด้วยดินสอ แล้วรันด้วยมือทีละขั้นบนรถบัส ผมหาบั๊กเจอและแก้ได้ และต้องจัดวางฟังก์ชันใหม่ทั้งหมด
เหมือนเป็นบทเรียนว่า การจงใจจำกัดความสามารถในการทำสิ่งต่าง ๆ ด้วยวิธีที่ง่าย บางครั้งอาจนำไปสู่โค้ดที่ผ่านการไตร่ตรองอย่างดีได้
ถึงอย่างนั้นปกติผมก็ไม่ได้ทำแบบนี้ ผมก็เขียนสไนเป็ตคร่าว ๆ แล้ววนทำซ้ำ หรือใช้ดีบักเกอร์รันทีละบรรทัดทันทีเหมือนกัน อาจต้องกลับมาคิดใหม่ก็ได้
แต่ถ้าทำทุกอย่างบนกระดาษ สุดท้ายมันก็แทบไม่ต่างจากการทำบนคอมพิวเตอร์โดยตรง เราจะจดทุกอย่างลงไปหมด และสูญเสียระดับนามธรรมกับความรอบคอบนั้นไป
ตอนที่ผมเริ่มต้น เป็นช่วงปลายยุค “คอมพิวเตอร์ขนาดใหญ่”
ในอดีต “โปรแกรมเมอร์” มักใกล้เคียงกับเสมียนป้อนข้อมูล และมักเป็นผู้หญิง
ส่วนคนที่เขียนซอฟต์แวร์จริง ๆ กำลังเขียนโปรแกรมลงบนกระดาษในออฟฟิศที่เต็มไปด้วยควันบุหรี่
เวลาประมวลผลมีราคาแพงและหายาก ถ้าเกิดบั๊กตอนรัน ก็ไม่มีโอกาสแก้จนกว่าจะจองเวลาป้อนข้อมูลและเวลารัน CPU ได้อีกครั้ง
ดังนั้นจึงส่งเสริมแนวทางแบบ วัดสองครั้ง ตัดครั้งเดียว
ซอฟต์แวร์ส่วนใหญ่ในตอนนั้นค่อนข้างเรียบง่ายเมื่อเทียบกับสิ่งที่เราถือเป็นเรื่องปกติในวันนี้ จึงทำแบบนั้นได้ง่ายกว่า อีกทั้งอินพุต/เอาต์พุตของซอฟต์แวร์ก็จำกัดอย่างยิ่ง คำว่า UI แทบยังไม่มี และการเชื่อมต่ออุปกรณ์ต่อพ่วงก็เป็นเรื่องใหญ่
ทุกวันนี้เวลาสร้างซอฟต์แวร์ เรามักใช้วิธี “โยนใส่กำแพงแล้วดูว่าอะไรติดอยู่” เขียนโค้ดครึ่ง ๆ กลาง ๆ แล้วดีบักใน IDE ง่ายกว่า
การพัฒนาซอฟต์แวร์ของผมค่อนข้างเป็นแบบ ทำซ้ำเป็นรอบ ๆ และผมเคยเขียนไว้ที่นี่: https://littlegreenviper.com/miscellany/evolutionary-design-...
ผมจำได้ว่าตอนทำงานมหาวิทยาลัย ต้องเขียนเคอร์เนลระบบปฏิบัติการแบบง่าย ๆ
ผมไม่ค่อยรู้ C และไม่รู้ว่าเคอร์เนลทำอะไรนอกจากในเชิงทฤษฎี แต่ต้องเขียนโค้ด C หลายร้อยบรรทัดสำหรับการจัดการงาน
ผมคิดว่าถ้าโปรแกรมนี้ไม่ทำงาน แทบจะไม่มีทางดีบักได้ เพราะเป็นโค้ดขนาน และบั๊กก็คงปรากฏเป็น race condition ที่ระบุไม่ได้
ผมไล่เหตุผลของระบบทั้งหมด และใช้เวลาหลายวันคิดอย่างหนักกับฟังก์ชันเล็ก ๆ ที่เป็นอิสระต่อกันจำนวนมากขณะเขียน
จากนั้นพอคอมไพล์และรัน หลังแก้ข้อผิดพลาดคอมไพล์แบบชัดเจนอย่าง “ลืมเซมิโคลอน” แล้ว มันก็ทำงานตั้งแต่รันครั้งแรก
ทุกครั้งที่มีความสำเร็จน่าประทับใจถูกโพสต์ขึ้นมา คอมเมนต์ก็มักเอาแต่จับผิด อยากให้เลิกเสียที
ไม่ใช่คนที่ออกแบบ ตัวจัดการหน่วยความจำเสมือน สำหรับระบบปฏิบัติการใหม่ แต่เป็นเพียงฟันเฟืองในเครื่องจักรที่แปลง SQL query เป็น HTML เพื่อแสดงโฆษณาให้เด็ก ๆ และผู้สูงอายุ
จึงหลีกเลี่ยงไม่ได้ที่จะกลายเป็นคนเย้ยหยันและขมขื่น
จริง ๆ แล้วไม่ควรเลิก การถกเถียงก็ควรเป็นแบบนั้นแหละ
มันถูกอยู่ระดับหนึ่ง แต่คำถามที่ดีกว่าและพาไปในทางบวกคือ เราจะไปถึงสภาวะที่ ความสำเร็จคล้ายกันเป็นไปได้ ในสภาพแวดล้อมบริษัทปัจจุบันได้อย่างไร?
ทุกครั้งที่เห็นปฏิกิริยาแบบนี้ โดยทั่วไปก็เป็นเช่นนั้นเอง ตะแกรงของการจัดอันดับโดยผู้ใช้แค่ ต้องใช้เวลาสักหน่อย ในการดันคอมเมนต์ที่ดีกว่าขึ้นมา
ถ้าคนคนนี้ต้องเผชิญ ความท้าทาย แบบที่ผมเจอ เขาคงทรุดลงไปตรงนั้นเลย
ซอฟต์แวร์ในสมัยนั้นมีขนาดเล็กกว่ามาก
ทุกวันนี้ แค่โปรเจกต์ใหญ่กว่าโปรแกรมของเล่นขึ้นมานิดเดียว ส่วนใหญ่ก็มีขนาดเป็น ระดับเมกะไบต์ แล้ว และเป็นไปไม่ได้ที่จะ “เขียนไล่ลงไป” เป็นไฟล์เดียว
นี่ใหญ่และซับซ้อนกว่าสิ่งที่คนส่วนใหญ่ทำงานกันในปัจจุบัน ทุกวันนี้งานจำนวนมากแทบจะเป็นแค่ glue code ที่โอ้อวดเกินจริง เอาของอย่าง CRUD/REST มาต่อเข้าด้วยกัน
มันอาจเล็กกว่าจำนวนบรรทัดโค้ดของทั้งโปรเจกต์ แต่ใหญ่กว่าหน่วยงานที่ผู้คนจัดการกันอยู่ อีกทั้งนี่ก็เป็นเพียงส่วนหนึ่งของโค้ดระบบปฏิบัติการทั้งหมดด้วย
นี่คือ “ตัวจัดการที่บริหารข้อมูลคำอธิบายไฟล์” ทั้งหมด ต้องขนย้ายข้อมูลไฟล์ระหว่างดิสก์กับหน่วยความจำ จัดการพูลบัฟเฟอร์หน่วยความจำที่ใช้ร่วมกัน และยังต้องจัดการพื้นที่ดิสก์สำหรับข้อมูลนั้นด้วย
ลองให้โปรแกรมเมอร์ส่วนใหญ่ในปัจจุบันเขียนสิ่งที่มีข้อกำหนดและ semantics แบบเดียวกัน ด้วยภาษาที่ตัวเองเลือกในวันนี้ดูสิ
คนส่วนใหญ่คงหลงทางตั้งแต่ขั้นจินตนาการถึงมันแล้ว ไม่ต้องพูดถึงการเขียนลงกระดาษ พิมพ์เข้าไป แล้วทำให้มันทำงานได้เลย
ส่วนเล็ก ๆ ในนั้นเป็น URL ของชิ้นส่วนอิเล็กทรอนิกส์ แต่เกือบ 90% เป็นข้อความภาษาอังกฤษล้วน ๆ อีก 10% เป็นข้อความที่อ้างมาจากงานเขียนของคนอื่น หน้าเว็บ application note ของผู้ผลิต หนังสือ ฯลฯ
มันเป็นไฟล์เดียว และก็คงจะยังเป็นไฟล์เดียวต่อไป ไม่ใช่แค่ตลอดช่วงที่เหลือของปีนี้เท่านั้น ถ้าเดินต่อด้วยอัตราเดียวกันก็จะเป็น 12 เมกะไบต์ ซึ่งไม่ได้เป็นเรื่องเป็นไปไม่ได้เลย
ถ้าสนใจก็ git clone http://canonical.org/~kragen/sw/leatherdrink.git ได้
ตอนนี้ commit toolchain ของ avr ไว้ด้วย เลยเกือบ 200 เมกะไบต์ และยังมีรูปถ่าย วิดีโอ schematic อะไรพวกนั้นด้วย
ถ้าเป็นภาษาโปรแกรม จำนวนไบต์ที่เพิ่มขึ้นต่อเดือนคงน้อยกว่านี้ แต่อาจต่างกันสักห้าเท่า
โค้ดที่ André Bensoussan เขียนอยู่ที่นี่: https://multicians.org/vtoc_man.html
ตอนนั่งลงที่โต๊ะเพื่อเริ่มงาน และกำลังจะทำงานที่ไม่อยากทำให้เสร็จ แน่นอนว่าใจผมก็วอกแวก อยากไปดูข่าวใน reddit หรือ HN
พอเปิด HN ขึ้นมา หัวข้อแรกก็คืออันนี้
“ทำได้”
มันช่วยสร้างแรงบันดาลใจ
ป.ล. แน่นอนว่าผมอ่านบทความด้วย :)
“André ทำสิ่งนี้ได้อย่างไรโดยไม่มีเครื่องมืออะไรเลยนอกจากดินสอ?”
ตอนผมเข้าโรงเรียนมัธยมตอนอายุ 14 ในคาบเขียนโปรแกรม เราเขียนโค้ดส่วนใหญ่ลงบนกระดาษ
ผมเป็นเด็กยากจนในประเทศยากจน ไม่ใช่แค่ไม่มี PC ที่บ้านเท่านั้น แต่ “คอมพิวเตอร์” ไม่กี่เครื่องในห้องคอมพิวเตอร์ของโรงเรียนก็เป็นเครื่องโคลน ZX Spectrum ที่รัน Turbo Pascal ซึ่งเป็นภาษาโปรแกรมที่เราใช้กันตอนนั้นไม่ได้