1 คำนำ (Draft)
มาระยะหนึ่งแล้วที่ผมมีความคิดที่จะเขียนหนังสือเกี่ยวกับทฤษฎีcategory โดยเน้นไปที่โปรแกรมเมอร์ และขอย้ำว่าไม่ใช่นักวิทยาการคอมพิวเตอร์แต่เป็นโปรแกรมเมอร์ เป็นวิศวกรไม่ใช่นักวิทยาศาสตร์ ผมรู้ว่านี่อาจจะฟังดูเหมือนเพี้ยนและผมก็แอบกลัวจริงๆ ผมไม่สามารถปฏิเสธได้ว่ามีช่องว่างขนาดใหญ่ระหว่างวิทยาศาสตร์กับวิศวกรรม ก็เพราะผมเคยทำงานอยู่ทั้งสองฝั่งของรอยแตก แต่ตลอดเวลาผมรู้สึกถึงแรงผลักดันอย่างมากในการอธิบายสิ่งต่างๆ ผมมีคำชื่นชมอย่างล้นหลามต่อริชาร์ด ไฟน์แมนที่คือเป็นผู้เชี่ยวชาญด้านการอธิบายแบบง่ายๆ ผมรู้ว่าผมไม่ไช่ไฟน์แมนแต่ผมจะพยายามให้ถึงที่สุด ผมเริ่มจากการเผยแพร่คำนำนี้(ที่ควรที่จะให้แรงบันดาลใจให้กับผู้อ่านในการเรียนทฤษฎีcategory) เพื่อหวังเป็นให้เป็นการเริ่มต้นของบทสนทนาและชักชวนให้มีข้อเสนอแนะต่างๆ1
สิ่งที่ผมจะทำ ในเพียงไม่กี่ย่อหน้าคือการทำให้คุณเชื่อว่าหนังสือเล่มนี้ถูกเขียนมาสำหรับคุณ และไม่ว่าจะมีคำแย้งแบบไหนที่คุณอาจจะมี ก็ตามในการเรียนสาขาในคณิตศาสตร์ที่นามธรรมที่สุดใน”เวลาว่างที่เหลือเฟือ”ของคุณนั้นไม่มีน้ำหนักเลย
ความมั่นใจของผมนั้นมาจากข้อสังเกตต่างๆ อย่างแรกคือทฤษฎีcategoryคือขุมสมบัติของไอเดียต่างๆในการเขียนโปรแกรมที่มีประโยชน์อย่างมาก คนที่เขียน Haskell ได้นำทรัพยากรเหล่านี้มาใช้ตั้งนานแล้ว และไอเดียต่างๆเหล่านี้ได้ค่อยๆซึมไปยังภาษาอื่นๆ แต่กระบวนการนี้นั้นช้าเกินไปเราจึงจำเป็นต้องเร่งมัน
อย่างที่สอง ได้มีคณิตศาสตร์หลากหลายรูปแบบและพวกมันดึงดูดผู้ติดตามหลายรูปแบบ คุณอาจจะไม่ชอบ calculus หรือ พีชคณิต(algebra) แต่นั้นไม่ได้หมายความว่าคุณจะไม่สนุกไปกับทฤษฎีcategory โดยที่ผมอาจจะพูดได้ว่าทฤษฎีcategoryคือประเภทของคณิตศาสตร์ที่ค่อนข้างที่จะเหมาะสมสำหรับวิธีคิดของโปรแกรมเมอร์ นั่นก็เพราะว่าทฤษฎีcategoryให้ความสนใจกับโครงสร้างแทนที่จะเป็นสิ่งที่เฉพาะเจาะจง มันทำงานกับโครงสร้างที่ทำให้โปรแกรมนั้นประกอบกันได้ (Composable)
การประกอบกัน (Composition) เป็นรากฐานที่แท้จริงของทฤษฎีcategory (มันคือส่วนหนึ่งของคำนิยามของcategoryเอง) และผมจะเสนออย่างเต็มที่ว่าการประกอบกันคือแก่นแท้ของการเขียนโปรแกรม เราได้ทำการประกอบสิ่งต่างๆมาโดยตลอด ตั้งนานก่อนที่แนวคิดของsubroutineที่เกิดมาจากวิศวกรผู้ยิ่งใหญ่เสียอีก ในอดีตที่ผ่านมาหลักการของการเขียนโปรแกรมเชิงโครงสร้าง (structural programming) ได้ปฏิวัติวิธีการเขียนโปรแกรมเพราะว่า หลักการเหล่านี้ทำให้ชิ้นส่วนของโค้ดต่างๆสามารถประกอบกันได้ แล้วก็ตามมาด้วย object oriented programming ที่แทบทั้งหมดก็เกี่ยวกับการประกอบวัตถุต่างๆ functional programming นั้นไม่ได้แค่เกี่ยวกับการประกอบกันของfunctionและโครงสร้างข้อมูลแบบพีชคณิต (algebraic data structures) (ที่ทำให้concurrencyประกอบเข้ากันได้) และเป็นบางอย่างที่การเขียนโปรแกรมในแบบอื่นๆไม่สามารถทำได้
อย่างที่สาม ผมมีอาวุธลับที่2จะทำการย่อยคณิตศาสตร์ให้มันง่ายกับ(การอ่านโดย)โปรแกรมเมอร์ ในตอนที่คุณเป็นนักคณิตศาสตร์มืออาชีพ คุณต้องระวังเป็นอย่างมากที่จะทำให้การข้อสมมติของคุณถูกต้องเสียก่อน จำเป็นต้องตรวจสอบทุกๆstatementอย่างระเอียดและสร้างข้อพิสูจน์ที่รัดกุม นี่จึงทำให้การอ่านงานวิจัยหรือหนังสือทางคณิตศาสตร์นั้นยุ่งยากสำหรับคนภายนอก ผมได้จบฟิสิกส์มาและในฟิสิกส์นั้นเราได้มีความก้าวหน้าอย่างน่าเหลือเชื่อโดยการใช้เหตุผลในแบบที่ไม่ต้องรัดกุมมากนัก นักคณิตศาสตร์ได้หัวเราะให้กับ Dirac delta function ที่ถูกสร้างมาโดยนักฟิสิกส์ผู้ยิ่งใหญ่อย่าง P. A. M. Dirac เพื่อที่จะแก้สมการเชิงอนุพันธ์บางตัว แต่พวกเขาก็หยุดหัวเราะในตอนที่พวกเขาค้นพบสาขาของcalculusที่เรียกว่าทฤษฎีdistribution ที่ทำให้แนวคิดที่ลึกซึ้ง(insights)ของDiracเป็นรัดกุม(formalized)
แน่นอนว่าใช้เหตุผล(ทางคณิตศาสตร์)ที่ไม่รัดกุม ก็มักจะทำให้คุณพูดในสิ่งที่ผิดอย่างชัดเจน ดังนั้นผมจะพยายามทำให้มั่นใจได้ว่าได้มีทฤษฎีทางคณิตศาสตร์ที่แน่นหนาในการสนับสนุนการใช้เหตุผลที่ไม่รัดกุม ผมได้มีหนังสือ Category Theory for the Working Mathematician ที่เขียนโดย Saunders Mac Lane อยู่ไว้ข้างเตียง
เนื่องว่านี้คือทฤษฎีcategoryสำหรับโปรแกรมเมอร์ ผมจะแสดงทุกๆแนวคิดที่สำคัญ (ทางคณิตศาสตร์) ผ่านโค้ดคอมพิวเตอร์ คุณอาจจะได้ยินมาว่า ภาษาแบบFunctionalต่างๆนั้นมีความใกล้เคียงกับคณิตศาสตร์มากกว่าภาษาแบบimperativeที่เป็นที่นิยมมากกว่า ภาษาประเภทเหล่านี้จะมีความสามารถในการabstractingที่มากกว่าเช่นกัน ดังนั้นจึงมีความต้องการที่จะต้องเรียนHaskellก่อน เพื่อที่จะได้เห็นประโยชน์ของทฤษฎีcategory แต่นี้ไม่ได้ความหมายว่าทฤษฎีcategoryไม่สามารถถูกใช้งานนอกเหนือไปจากการเขียนโปรแกรมแบบfunctional ดังนั้นผมก็จะให้ตัวอย่างจำนวนมากในภาษาC++ นั้นก็หมายความว่าคุณจะต้องที่จะก้าวข้ามsyntaxที่ไม่ค่อยสวยงาม รูปแบบต่างๆ(patterns)ที่อาจจะไม่เด่นขึ้นมาจากพื้นหลังที่มีความความเวิ่นเว้อและคุณอาจจะถูกบังคับให้ทำการ copyและpasteแทนที่จะเป็นการทำabstractionที่ขั้นที่สูงกว่า เหมือนกับโปรแกรมเมอร์C++หลายคน
แต่คุณจะไม่สามารถหนีได้ถ้าHaskellยังมีความเกี่ยวค่อง คุณไม่จำเป็นต้องเป็นโปรแกรมเมอร์Haskell แต่คุณต้องการมันในฐานะภาษาสำหรับการร่างและจดไอเดียต่างๆที่จะถูกเขียนในภาษาC++ และนี้คือวิธีการที่ผมเริ่มต้นกับHaskellจริงๆ ผมพบว่าว่าsyntaxที่รวบรัดและระบบtype ที่มีความสามารถสูงเป็นตัวช่วยที่ดีในการทำความเข้าใจและการเขียนtemplates โครงสร้างข้อมูล (data structure) และ algorithms แต่เนื่องว่าผมไม่ได้คาดหวังให้คุณคนที่อ่านรู้การเขียนในภาษาHaskell ผมจึงจะแนะนำมันอย่างช้าๆและอธิบายทุกๆอย่างระหว่างทาง
ถ้าคุณเป็นโปรแกรมเมอร์ที่มีประสบการณ์ คุณอาจจะถามตัวเองว่า: เราได้เขียนโปรแกรมมาตั้งนานโดยที่ไม่ต้องกังวลเกี่ยวกับทฤษฎีcategoryหรือวิธีการแบบfunctional แล้วมีอะไรบ้างที่เปลี่ยน? แน่นอนว่าเราไม่สามารถที่จะมองข้ามการที่ว่าได้มีการชึมเข้ามาของfeaturesแบบfunctionalในภาษาแบบimperativeอย่างช้าๆ แม้กระทั้งJavaที่เป็นดั่งปราการของobject oriented programmingก็อนุญาตให้lambdaเข้ามาได้ C++ก็ได้กำลังพัฒนาอย่างก้าวกระโดด (ที่มีมาตรฐานใหม่แทบทุกไม่กี่ปี) เพื่อที่จะตามโลกที่กำลังเปลี่ยนแปลงให้ทัน การขยับแบบนี้ก็เพื่อเตรียมตัวสำหรับการเปลี่ยนแปลงอย่างพลิกผัน (disruptive change) หรือนักฟิสิกส์จะเรียกว่าการเปลี่ยนวัฏภาค (phase transition) ถ้าคุณอุ่นนำ้ไปเรื่อยๆมันก็จะเดือดในสักวัน เราอยู่ในตำแหน่งของกบที่จะต้องเลือกว่าเราจะว่ายต่อไปในน้ำที่ร้อนมากขึ้นหรือเริ่มที่จะหาทางเลือกอื่นๆ
หนึ่งในสิ่งที่ขับเคลื่อนการเปลี่ยนแปลงครั้งใหญ่คือการปฎิวัติมัลติคอร์(multicore) ประเภทของภาษาโปรแกรมที่ยังอยู่ (อย่างการเขียนโปรแกรมแบบobject oriented) ก็ไม่ได้เสนออะไรใหม่ให้คุณเลยในสิ่งที่เกี่ยวกับ concurrencyและการทำงานคู่ขนาน (parellelism) ซ้ำร้ายยังสนับสนุนการออกแบบที่เต็มไปด้วยbugและอันตราย การปกป้องข้อมูล(data hinder) ซึ่งเป็นแนวคิดตั้งต้นของภาษาแบบobject oriented ในตอนที่ต้องถูกนำเข้าไปผสมกับการsharingและการmutation(เปลี่ยนรูป) กลับกลายมาเป็นจุดเริ่มต้นของdata races แนวคิดของการรวมกันระหว่างmutexกับข้อมูลที่มันปกป้องเป็นสิ่งที่ดีแต่น่าเสียดายที่lockนั้นไม่สามารถที่จะประกอบกันได้ และการซ้อนlockทำให้ปัญหาdeadlocksเกิดง่ายขึ้นและยากต่อการแก้
แต่แม้กระทั้งในกรณีที่ไม่มีconcurrency ในความชับช้อนของระบบของโปรแกรมที่มีมากขึ้น ก็เป็นการทดสอบขีดจำกัด ของความสามารถในการขยายตัวของรูปแบบการเขียนของimperative หรือในอีกคำอธิบายที่ง่ายขึ้น ก็หมายความว่าผลข้างเคียง(side effects)นั้นมีมากจนล้นมือ โดยที่ functionต่างๆที่มีผลข้างเคียงมักจะสะดวกและง่ายต่อการเขียน ผลข้างเคียงต่างๆของพวกมันเหล่านี้สามารถ(ในทางหลักการ)ถูกเขียนลงใปในชื่อหรือcommentต่างๆ ตัวอย่างเช่นfunctionที่มีชื่อว่า SetPassword หรือ WriteFile นั้นก็ชัดเจนมากว่ามันจะทำการเปลี่ยนแปลงบางสถานะและก่อให้เกิดผลข้างเคียงและเราก็คุ้นเคยกับการจัดการสิ่งเหล่านี้ แต่ปัญหาจะเริ่มปรากฏในตอนที่เราเริ่มที่จะประกอบfunctionต่างๆที่มีผลข้างเคียงต่อเข้ากับfunctionต่างๆที่ก็มีผลข้างเคียงและต่อๆกันไป ไม่ได้เพราะว่าผลข้างเคียงแย่ในตัวมันเอง แต่คือการที่พวกมันถูกซ่อนจากสายตาที่ทำให้การจัดการในขนาดที่กว้างขึ้นเป็นไปไม่ได้ ผลข้างเคียงไม่สามารถถูกใช้เป็นจำนวนมากได้และการเขียนโปรแกรมแบบimperativeนั้นเกี่ยวข้องกับผลข้างเคียงทั้งสิ้น
การเปลี่ยนแปลงของhardwareและความซับซ้อนของโปรแกรมที่มีมากขึ้นบังคับให้เราต้องคิดใหม่เกี่ยวกับรากฐานของการเขียนโปรแกรม เหมือนกับนักก่อสร้างมหาวิหารยิ่งใหญ่แบบgothicของยุโรป เราได้ฝึกฝนการฝีมือของเราจนถึงจุดที่มีจำกัดทางวัสดุและโครงสร้าง ได้มีมหาวิหารgothicที่ยังสร้างไม่เสร็จในBeauvais3ที่ฝรั่งเศสที่เป็นเหมือนพยานให้กับ การฝ่าฟันของมนุษย์ที่ลึกซึ้งต่อข้อจำกัดต่างๆเหล่านี้ มันเคยถูกคาดหวังให้ชนะในทั้งความสูงและความสว่างเมื่อเทียบกับวิหารที่มีมาก่อนแต่มันกลับต้องมีปัญหาของการทรุดตัวอยู่อย่างเรื่อยๆ มาตรการเฉพาะกิจอย่างแท่งเหล็กและสิ่งรองรับที่เป็นไม้ ป้องกันไม่ให้มันยุบตัวลงมา แต่เห็นได้ชัดว่ามีสิ่งที่ผิดพลาดหลายอย่าง ในมุมมองสมัยใหม่ มันเป็นปาฎิหาริย์ที่โครงสร้างgothicได้สร้างเสร็จโดยที่ไม่ต้องมีการช่วยเหลือจากวัสดุศาสตร์ (materials science), การสร้างแบบจำลองคอมพิวเตอร์ (computer model), finite element analysis และคณิตศาสตร์หรือฟิสิกส์ทั่วไป ผมหวังว่าในคนในคนรุ่นถัดๆไปจะมีคำชื่นชมในแบบคล้ายๆกันต่อทักษะของการเขียนโปรแกรมที่เราได้แสดงออกมาผ่านการสร้างระบบปฏิบัติการที่ชับช้อน web serversและโครงสร้างพื้นฐานของอินเทอร์เน็ตและถ้าให้พูดอย่างตรงๆแล้วพวกเขาจะควรที่จะชื่นชมเพราะว่าเราได้ทำสิ่งเหล่านี้จากรากฐาน ทางเชิงทฤษฎีที่บอบบาง เราควรที่จะแก้รากฐานเหล่านี้ถ้าเราต้องการที่จะเดินไปต่อข้างหน้า
คุณสามารถที่จะดูผมสอนสิ่งเหล่านี้ให้กับผู้ชมแบบสดๆที่ https://goo.gl/GT2UWU หรือหรือค้นหาไปที่ “bartosz milewski category theory” ใน YouTube.↩︎
(Translator note): In the original, the secret weapon is “butcher’s knife”, which is a pun, since he is going to “butcher” the math.↩︎