- Ruby ตอบโต้กับมุมมองที่มองว่าเป็นภาษาที่ "ไม่จริงจัง" ด้วยความจริงที่ว่า Ruby คือ ภาษาที่ทำให้การเขียนโปรแกรมเป็นเรื่องที่เป็นมนุษย์และมีความสนุก
- ชุมชนต้นกำเนิดของ Ruby เริ่มต้นขึ้นราวกับ การกบฏเล็ก ๆ ที่มีความรื่นเริง และยึดความชัดเจนกับ ความชัดเจนและความเข้าถึงได้ มากกว่าความซับซ้อน
- ตัวอย่างจากบริการขนาดใหญ่ระดับองค์กรอย่าง Shopify, Doximity, GitHub ที่ถูกดำเนินการจริงด้วย Ruby แสดงให้เห็นว่าผลลัพธ์เชิงปฏิบัติเป็นจริง
- แก่นแท้ของ Ruby คือประสบการณ์ของผู้เขียนโค้ดและวัฒนธรรมการพัฒนาที่ยั่งยืน ซึ่งไม่ใช่แค่ความคิดถึงอดีต แต่เป็นทัศนคติของความขอบคุณและการให้เกียรติ
- ในอนาคตการพัฒนาซอฟต์แวร์ ความอ่านง่าย การบำรุงรักษา และความสนุก จะยิ่งมีความสำคัญมากขึ้น โดยคุณค่าของ Ruby จะยังคงเป็น จุดอ้างอิงที่มีความหมาย ต่อไป
Ruby กับแนวคิดของ “ความจริงจัง”
- คำถามว่า “Ruby เป็นภาษาโปรแกรมมิ่งที่จริงจังหรือไม่?” สะท้อนความแตกต่างเรื่องการรับรู้ว่า การเขียนโปรแกรมควรมีอารมณ์แบบใด
- บางคนมองว่าเครื่องมือที่ใช้ได้อย่างสนุกหมายความว่าไม่จริงจัง แต่ Ruby ไม่เห็นด้วยกับคำจำกัดความแบบนั้น
- ยุคแรกของ Ruby เต็มไปด้วยชุมชนเล็ก ๆ และพลังสดใสแบบสนุกสนาน ซึ่งแสดงให้เห็นว่าการเขียนโปรแกรมไม่จำเป็นต้องกดดัน
- ผู้วิจารณ์ในช่วงนั้นส่วนใหญ่คือ สถาปนิก Java หรือผู้พัฒนาองค์กรแบบดั้งเดิม และชุมชน Ruby ไม่ได้ใส่ใจสิ่งเหล่านั้น โดยโฟกัสไปที่การพัฒนาผลิตภัณฑ์จริง
เน้นความเข้าถึงได้และประสิทธิผล
- Ruby มุ่งไปที่ ความเข้าถึงได้ (approachability) ไม่ใช่เพียงความเรียบง่าย เพื่อช่วยให้ผู้เริ่มต้นและทีมขนาดเล็กเติบโตได้อย่างรวดเร็ว
- มากกว่าทฤษฎีที่ซับซ้อน Ruby ให้ความสำคัญกับ โมเมนตัมและความชัดเจน ทำให้นักพัฒนาสามารถพัฒนาได้ต่อเนื่องโดยไม่วิตกกังวล
- ด้วยคุณสมบัตินี้ บูตแคมป์และสตาร์ทอัป หลายแห่งจึงเลือกใช้ Ruby ซึ่งเหมาะกับสภาพแวดล้อมที่ให้ความสำคัญกับ ความเร็วและความคิดสร้างสรรค์
- เหมือนกรณีของ Twitter Ruby ช่วยบริษัทเติบโตได้อย่างเพียงพอ และการเปลี่ยนไปใช้เทคโนโลยีอื่นในภายหลังถูกนำเสนอเป็น ผลลัพธ์ของความสำเร็จ
ความน่าเชื่อถือในงานจริงและกรณีศึกษา
- จากประสบการณ์ที่ปรึกษามากว่าสิบปี ไม่เคยมีทีมใดล้มเหลวเพราะเลือก Ruby ตรงกันข้าม ความซับซ้อน ความลังเล และความจริงจังที่มากเกินไป ต่างเป็นปัจจัยล้มเหลวมากกว่า
- Ruby ได้รับการประเมินว่าเป็นภาษาที่ไม่ขัดขวางนักพัฒนา ทำให้สามารถ โฟกัสงานหลัก ได้
- บริการสำคัญอย่าง Shopify, Doximity, GitHub ที่ใช้ Ruby เพื่อการทำงานได้เป็นหลักถูกยกเป็น หลักฐานเชิงผลลัพธ์ (proof) ไม่ใช่แค่ความรู้สึก
วัฒนธรรม Ruby และปรัชญาพัฒนาการที่เน้นมนุษย์
- Ruby ดึงดูดผู้คนที่ให้ความสำคัญกับ การรับรู้ในการเขียนโค้ดและประสบการณ์การอ่าน ซึ่งไม่ใช่ความคิดถึงอดีต แต่เป็น แนวทางการสร้างซอฟต์แวร์อย่างยั่งยืน
- ชุมชน Ruby ให้ความสำคัญกับ ความมีอารมณ์และความเป็นมนุษย์เป็นศูนย์กลาง และย้ำว่า การเขียนโปรแกรมเป็นการกระทำเพื่อผู้คน
- ความต่างกับผู้ที่ชื่นชอบภาษาอื่นเป็นเพียง เรื่องรสนิยม และ Ruby ไม่พยายามโน้มน้าวให้ทุกคนเชื่อ
การพัฒนาซอฟต์แวร์ในอนาคตกับบทบาทของ Ruby
- การพัฒนาซอฟต์แวร์ในอนาคตจะไม่ถูกครอบงำโดยภาษา รูปแบบการคิด หรือแนวความคิดเพียงแบบเดียว แต่จะขยายไปในรูปแบบที่ ผสมผสานและยืดหยุ่น
- ใน ยุคที่ AI เขียนโค้ด ความชัดเจนและการบำรุงรักษาจะยิ่งสำคัญขึ้น และในสภาพแวดล้อมที่ภาวะ burnout เป็นเรื่องปกติ ความสนุกจะกลายเป็นคุณค่าหลัก
- คุณค่าในจุดเด่นของ Ruby อย่าง ความชัดเจน ความเอาใจใส่ และการมุ่งมนุษย์เป็นศูนย์กลาง ไม่ใช่มรดกของอดีต แต่จะเป็น เกณฑ์อ้างอิงในอนาคต
โค้ดที่สั่นสะเทือนมากว่าความจริงจัง
- สังคมและธุรกิจให้รางวัลแก่ การก้องกังวาน (resonance) และ ความชัดเจน ความเป็นมนุษย์ มากกว่าความจริงจัง
- ผู้สมัคร นักร้อง นักศิลปะ สตาร์ทอัป และวิศวกรที่ดูจริงจังไม่ได้แปลว่าจะประสบความสำเร็จเสมอไป
- Ruby มุ่งสู่ โค้ดเพื่อทีม และ การเขียนโปรแกรมเพื่อผู้คน ซึ่งแนวทางนี้ช่วยให้ภาคอุตสาหกรรมยังคงเป็นมนุษย์มากขึ้น
- นักพัฒนาที่มีความอยากรู้อยากเห็นและร่าเริง จะมีบทบาทสำคัญในระบบนิเวศเทคโนโลยีแห่งอนาคต และ Ruby จะยังคงเป็น ภาษาอันทรงคุณค่า ในกระแสนี้
บทสรุป
- คำถามว่า “Ruby เป็นภาษาโปรแกรมมิ่งที่จริงจังหรือไม่?” คือคำถามที่ไม่เหมาะสม
- คำถามที่เหมาะสมยิ่งกว่าคือ “Ruby ยังคง สามารถมีส่วนร่วมอย่างมีความหมายกับซอฟต์แวร์รุ่นถัดไปได้หรือไม่” และคำตอบคือ ใช่
- หากคำว่า ‘ไม่จริงจัง’ คือคำอธิบายหนึ่งเดียว นั่นคือเหตุผลที่ Ruby ควรเป็นส่วนหนึ่งของการสนทนานี้
2 ความคิดเห็น
คำตอบต่อ "Ruby ไม่ใช่ภาษาโปรแกรมที่จริงจัง"
ความเห็นบน Hacker News
ต่อให้ Ruby เป็นสาเหตุก็ตาม การเลือกนั้นก็ทำให้ธุรกิจเริ่มต้นขึ้นและประสบความสำเร็จครั้งแรกได้
ปัญหาของ Twitter ไม่ได้อยู่ที่ภาษา แต่เป็นสถานการณ์เฉพาะอย่าง การกระจายข้อมูลขนาดใหญ่ (celebrity tweet → ผู้ติดตามหลายล้านคน)
อีกทั้งก็ไม่มีใครพูดถึงสตาร์ตอัปที่ล้มเหลวทั้งที่ใช้ภาษาที่ “ขยายระบบได้ตั้งแต่แรก” — นี่คือ survivorship bias แบบคลาสสิก
ถ้าดูที่หน้าผู้เขียนบน Wired ก็ดูเหมือนว่าเขาจะจงใจเขียนแบบสร้างประเด็นขัดแย้งเป็นกลยุทธ์
ฉันก็ยังคงกลับไปเป็นหนึ่งในคนส่วนใหญ่เงียบ ๆ ที่ยังสร้างซอฟต์แวร์มีประโยชน์ด้วย Ruby ต่อไป
เขาเพียงแค่ไล่เรียงข้อจำกัดในอดีต และมีความเป็นไปได้สูงว่าจริง ๆ แล้วปัญหาอยู่ที่โค้ดเบสที่เขารับผิดชอบ
แก่นของบทความแรกคือ “ไม่มีเหตุผลที่จะเลือก Ruby ใหม่ในปี 2025” และนั่นต่างหากที่ควรเป็นศูนย์กลางของการถกเถียง
แต่บทความนี้กลับไปในทางที่อาศัยอารมณ์ และน่าประหลาดที่มันเหมือนพิสูจน์ข้อกล่าวหาในบทความก่อนเองว่า Ruby ขับเคลื่อนด้วยอารมณ์
หลายคนที่ชอบ Elixir มอง Ruby ว่า ‘ไม่จริงจัง’ แต่ Elixir เองก็ได้รับอิทธิพลจาก Ruby อย่างมาก
หลายคนถูกดึงดูดโดย Elixir ที่ผสมผสานไวยากรณ์คุ้นเคยแบบ Ruby เข้ากับ พื้นฐานเชิงฟังก์ชัน
โดยเฉพาะอย่างยิ่งเพราะ BEAM runtime ทำให้คุณสมบัติด้านการปฏิบัติการต่างออกไปโดยสิ้นเชิง
BEAM ให้ความรู้สึกว่าไม่ใช่แค่ภาษา แต่เป็น ระบบสำหรับระบบ — สามารถติดตาม รีสตาร์ต และสังเกตการณ์ทุกอย่างได้
เพียงแต่ Crystal มีปัญหาเรื่อง ความนิยมต่ำ หนักกว่า Elixir อีก
ตาม อันดับ TIOBE Elixir ยังอยู่ใน 50 อันดับแรก
บทความแรกพูดแค่สถิติของ StackOverflow กับเรื่อง Twitter ส่วนบทความที่สองก็มีแค่ความคิดถึงอดีตกับเรื่องสุนทรียะ
การที่มันเป็นบทความที่มนุษย์เขียน ไม่ใช่ LLM กลับยิ่งทำให้หดหู่
แต่คือ “อยากให้ระบบที่กำลังรันอยู่เขียนด้วยภาษานี้ไหม”
มีไม่กี่คนหรอกที่คำตอบของสองคำถามนี้จะเหมือนกัน
ฉันชอบ Ocaml แต่ไม่อยากใช้กับระบบโปรดักชัน เพราะ ecosystem อ่อนและหาคนมาร่วมทีมยาก
Python ที่มี type annotation และเครื่องมือตรวจสอบก็ดูแลรักษาง่าย แต่ถ้าไม่มี สิ่งที่ขาดไม่ได้คือวัฒนธรรมการทำเอกสาร
ถ้าเป็นอย่างแรก COBOL ก็พอ แต่ถ้าเป็นอย่างหลัง ตัวเลือกอื่นก็น่าสนใจกว่า
ไม่ใช่เพราะอารมณ์ความรู้สึก แต่เพราะมัน สนุกเวลาเขียน — โดยเฉพาะเมื่อเทียบกับ JavaScript แล้วสนุกกว่ามาก
บทความที่โจมตี Ruby ให้ความรู้สึกแปลก ๆ
มีตัวอย่างความสำเร็จอย่าง Github, Twitter, Coinbase, Shopify อยู่แล้ว และ ปัญหาด้านการขยายระบบก็เป็นเพียงผลข้างเคียงของความสำเร็จ
Ruby เป็นเครื่องมือที่ยอดเยี่ยม และอยากแนะนำให้ตัดสินด้วยตัวเองว่ามันเหมาะกับโปรเจกต์ถัดไปหรือไม่
ถ้าข้ออ้างคือ “Ruby จะไม่มีวันขยายระบบได้ตลอดไป” ภาษาอื่นส่วนใหญ่ก็เป็นเหมือนกัน
สุดท้ายทั้งสองบทความก็เห็นตรงกันในแง่ที่ว่า “Ruby จะไม่ทำงานได้ตลอดไป”
สิ่งที่น่าสนใจคือ บทความต้นฉบับดูแคลนอันดับของ Ruby บน StackOverflow ว่าอยู่อันดับ 18
แต่จริง ๆ แล้วในปี 2024 มันอยู่อันดับ 14 และ Scala ที่บทความนั้นชมกลับต่ำกว่ามันอยู่ 9 อันดับ
ลิงก์แบบสำรวจ StackOverflow 2024
โค้ด Ruby ที่ฉันเขียนเมื่อ 10 ปีก่อน เช่น คอมไพเลอร์ offlineasm ของ WebKit ก็ยังทำงานได้ดีอยู่จนถึงตอนนี้
Ruby มีไวยากรณ์ที่สะอาดและมีพลังในการแสดงออกสูง แต่ก็ทำให้รู้สึกใช้งานยากเพราะ dynamic typing และ magic (พฤติกรรมโดยนัย)
มันอาจไม่เหมาะกับฉัน แต่เป็นภาษาที่เหมาะอย่างสมบูรณ์แบบสำหรับบางคน
แฟน ๆ มองว่ามันน่าทึ่งและสนุก แต่สำหรับบางคนมันกลับดูน่ากลัว
Flask ของ Python ก็ใช้ context local proxy ในลักษณะคล้ายกัน
ในทางกลับกัน Zig และ Go เกิดขึ้นมาเพื่อต่อต้านแนวคิดที่ว่า “ทุกอย่างต้องชัดเจนแบบ explicit” และ Rust อยู่ประมาณกึ่งกลาง
Rust เข้มงวด แต่ก็ยังมอบ ความสามารถในการแสดงออกแบบ DSL ได้อย่างสะอาด
ประสิทธิภาพของอัลกอริทึมดีขึ้น 10 เท่า บั๊กลดลงเพราะ immutability และ การรองรับ concurrency ก็ยอดเยี่ยม
ด้วย pattern matching และ guard ทำให้ boilerplate หายไป อีกทั้งไม่มี GIL และมี GC แยกตามโปรเซส
แม้จะมีช่วงเรียนรู้เล็กน้อย แต่ Elixir ขยายตัวได้ดีกว่ามากในแง่การดูแลระยะยาวและภาระงาน
ชุมชน Ruby ก็ยังยอดเยี่ยมเหมือนเดิม
แค่อยากให้ Elixir สามารถคอมไพล์เป็น ไฟล์ปฏิบัติการแบบเนทีฟ หรือรันในเบราว์เซอร์ได้
ยังคิดแบบ “คิดเป็น Ruby” อยู่ แต่โปรเจกต์ส่วนตัวทำด้วย Elixir/Erlang
ที่บริษัทใช้ Golang กับ Python แต่ไม่ค่อยสนุก
ส่วนสคริปต์ส่วนตัวยังเขียนด้วย Ruby อยู่
ฉันคิดว่าการถกเถียงที่มีคุณค่ากว่าคือการวิเคราะห์อย่างเยือกเย็นว่า คุณลักษณะของภาษา ส่งผลต่อคุณภาพของโค้ดอย่างไร มากกว่าความนิยมหรือความคุ้นเคย
การสนทนาแบบนั้นมักทำให้คนถอยหนีเพราะเจอแนวคิดอย่าง monad หรือ applicative แต่จริง ๆ แล้วนั่นแหละคือการถกเถียงที่มีประโยชน์
ยิ่งมี type และข้อจำกัดมากเท่าไร คุณภาพก็สูงขึ้น แต่ความเร็วในการพัฒนาและความยืดหยุ่นก็ลดลง
บทความแบบนี้เป็นเหมือน สารพิษ ที่คอยจุดสงครามภาษาใน HN
ไม่จำเป็นต้องเอาจริงเอาจังกับมัน
แต่ตอนนี้ Kotlin เหมาะกับฉันมากกว่า — เพราะ static typing และการออกแบบไวยากรณ์ที่ ergonomic
Ruby ดูไม่มั่นคงเมื่อโปรเจกต์ใหญ่ขึ้น แต่ก็ยังเป็นภาษาที่น่ารักสำหรับงานเล็ก ๆ อยู่เสมอ
อาจไม่ใช่ความผิดของภาษา แต่ยิ่งเป็น ภาษาที่มีราวกันตกด้านความปลอดภัยน้อย ก็ยิ่งมีแนวโน้มที่จะดึงดูดโค้ดอันตรายเข้ามา
if.classก็จะเห็นว่าไม่ได้เต็มร้อยขนาดนั้นถึงอย่างนั้น ในบรรดาภาษากระแสหลัก มันก็ยังใกล้เคียงที่สุดอยู่ดี