“วิธีการเรียนรู้/การเริ่มต้นงาน”: Trick ง่ายๆ ที่หลายคนมองข้าม

“การเรียนรู้” มันเป็นเรื่องโลกแตกสำหรับใครต่อใครหลายๆ คน ที่มีปัญหามากมาย แล้วก็ไม่ว่าจะเรียนรู้อะไรเท่าไหร่ ก็เหมือนกับจะไม่รู้เรื่อง หรือทำไม่ได้สักที …. ไม่ว่าจะเป็นการเรียนรู้ภาษาโปรแกรมใหม่ๆ หรือการเขียนโปรแกรมบนอุปกรณ์ใหม่ๆ การเรียนภาษาอังกฤษ หรือการเรียนรู้เรื่องอื่นๆ อีกหลายๆ เรื่อง … แล้วในที่สุดก็ต้องพึ่งพาทางลัดทั้งหลายทั้งปวง เพื่อให้ได้ผลลัพธ์ที่ตัวเองต้องการอย่างเร่งด่วนฉาบฉวย

วันนี้ผมก็เลยขอเสนอวิธี “ง่าย” ที่ได้ผลอย่างไม่น่าเชื่อในการเรียนรู้เรื่องอะไรต่ออะไรหลายๆ เรื่อง แล้วเป็นการอธิบายด้วยว่าทำไมเราถึงเรียนอะไรต่ออะไรกันยากเย็นนัก (เช่นพวกภาษาอังกฤษ หรือการเขียนโปรแกรม) ก็เพราะว่าเราเรียนรู้มันแบบ “ผิดวิธี” น่ะแหละ … คือเราเรียนรู้ด้วยการ “พยายามใช้มันเร็วเกินไป” ยกตัวอย่างเช่น บางคนเริ่มเรียนรู้การเขียนโปรแกรม จากโจทย์ที่ตัวเองทำไม่ได้ ไม่เคยทำได้ บางคนเริ่มเรียนภาษาอังกฤษ จากเนื้อหาที่ตัวเองก็ไม่ได้คุ้นเคยมาก่อน …. หรือที่เรียกว่า Unseen อะไรพวกนี้ … มันไม่ค่อยช่วยการเรียนรู้อะไรเท่าไหร่หรอก จริงๆ มันทำให้การเรียนรู้แย่ลงด้วยซ้ำไป

ลองพิจารณากันดูสักเล็กน้อยจะพบว่า … ในการอ่านหนังสือนั้น เรามีปัจจัยอย่างน้อยสองเรื่อง คือ “ภาษา” และ “เนื้อหา” ในขณะที่การเขียนโปรแกรมสักตัวนั้น เราก็มีปัจจัยพื้นฐานอย่างน้อย 2 เรื่อง คือ “ภาษา” และ “โครงสร้าง” ส่วนการพัฒนาโปรแกรมเพื่อตอบโจทย์ทางอะไรก็ตาม (เช่นโจทย์ทางธุรกิจ) จริงๆ นั้น ก็มีปัจจัยพื้นฐาน 2 เรื่องเช่นกัน คือ “ความสามารถในการพัฒนาโปรแกรม” และ “ความเข้าใจเรื่องราวนั้นๆ (เช่นความเข้าใจธุรกิจ)

Continue reading

หัดเขียนโปรแกรมยังไงให้เก่ง?

ถ้าจะมีคำถามที่ผมถูกถามมากที่สุดในฐานะ “โปรแกรมเมอร์” หรือ “โค้ดเดอร์” ก็คงเป็นคำถามนี้ (ไม่เกี่ยวกับคำถามที่ถามผมในฐานะอื่น) ซึ่งผมขอตอบยาวๆ ทีเดียวในนี้เลยก็แล้วกันนะครับ หวังว่าจะเป็นประโยชน์กันในระยะยาว

ก่อนอื่น ต้องทำความเข้าใจพื้นฐานก่อน ว่า

“การเขียนโปรแกรม”​ มันเป็นเรื่อง “Skill การสื่อสาร”

ครับ ซึ่งหลายคนอาจจะงงว่ามันเป็นแบบนี้ได้ยังไง ทำไมมันเป็นแบบนี้ ซึ่งผมขออธิบายสั้นๆ ว่า เพราะว่าเราจะต้องสื่อสารสิ่งที่เราคิด อย่างเป็นระบบเบียบเป็นขั้นเป็นตอน ให้คนที่โง่ที่สุด ที่บังเอิญขยันและคำนวนเร็ว อย่าง “คอมพิวเตอร์” สามารถนำไปปฏิบัติได้

ปัญหาอันดับแรกๆ ที่ผมพบก็คือ “คิดเป็นขั้นตอนไม่เป็น”

ถึงขนาดไม่สามารถคิดได้เลยว่าตั้งแต่ต้นทาง (ปัจจัยตั้งต้นที่มี) จะมีเส้นทางไปหาปลายทาง (ผลลัพธ์ที่ต้องการ) ได้อย่างไร โดยละเอียด ซึ่งอาจจะเกิดจากการไม่เคยคิดเป็นขั้นตอนมาเลย ทุกอย่างจะมีทางลัดไปหาขั้นตอนสุดท้ายเสมอๆ (สมัยเรียนจะเรียกว่า “สูตรลัด”) ดังนั้นจำรูปแบบให้ได้ และใช้สูตรลัดให้เป็น ก็เอาตัวรอดไปได้เรื่อยๆ แล้ว ซึ่งพอมาถึงเรื่องการเขียนโปรแกรม มันทำแบบนั้นไม่ได้ จะได้แต่โจทย์ง่ายๆ ซึ่งใช้งานอะไรจริงจังไม่ได้เลยเท่านั้น ซึ่งก็เหมือนกับสูตรลัดทั้งหลายแหล่ในฟิสิกส์หรือคณิตศาสตร์ ที่ใช้ได้แต่กับโจทย์ง่ายๆ เอามาใช้จริงจังอะไรไม่ได้เลย เหมือนกัน

ยกตัวอย่างง่ายๆ ในชีวิตประจำวัน เช่น “ถ่ายเอกสารชีทนี้มาแจกทุกคนในกลุ่ม” ซึ่งดูเหมือนจะง่ายนะ ทำกันประจำ แต่จะสื่อสารออกมาอย่างไร? เพียงแค่นี้พอหรือไม่? คำตอบคือ “ไม่พอ” เพราะถ้าเราไปพูดคำนี้กับคนที่ไม่รู้จักกลุ่มเรา จะรู้มั้ยว่ามีกี่คน? แม้แต่คนในกลุ่มเอง บางทียังต้อง “นับ” เลย

ดังนั้นในการสื่อสาร เราจะมีปัจจัยตั้งต้นคือ “ชีท” และ “กลุ่มคน”​ และปลายทางที่เราต้องการคือ “ทุกคนในกลุ่ม ได้รับชีทที่ถ่ายเอกสารแล้ว” ถ้าจะสื่อสารเป็นกระบวนการแบบโปรแกรม หรือฟังก์ชั่นทางคณิตศาสตร์ ก็จะได้ลักษณะนี้

จำนวน = นับ(คนในกลุ่ม)
ชีทที่ถ่ายเอกสารแล้ว = ถ่ายเอกสาร(ชีท, จำนวน)
คนที่ได้รับชีท = แจกจ่าย(ชีทที่ถ่ายเอกสารแล้ว, คนในกลุ่ม)

เป็นต้น

ปัญหาอันดับต่อไปที่ผมพบก็คือ การให้ความสำคัญกับตัวภาษาโปรแกรมมากไปในตอนแรก (แต่น้อยไปในระยะหลังจากนั้น)

จริงอยู่ การเขียนโปรแกรมจำเป็นต้องใช้ภาษาโปรแกรม แต่มันก็เหมือนกับการสื่อสารของคน ที่ต้องใช้ภาษาคนน่ะแหละ สิ่งที่สำคัญที่สุดที่ผู้เริ่มต้นจะต้องสนใจ คือ การนำไปใช้สื่อสารให้เร็วที่สุดที่จะเร็วได้ ไม่ต้องสนใจว่าจะรู้ภาษามากแค่ไหน ผมเคยเจอคนท่องดิกชันนารีได้เยอะมาก แต่สื่อสารไม่ได้ เวลาเจอคนต่างชาติก็ทำอะไรไม่ถูกเยอะแยะไป

ผมนึกถึงตอนที่ตัวเองไปเรียนที่ญี่ปุ่น ที่ผมอ่านอะไรจากการ์ตูนได้ (ผมเรียนภาษาญี่ปุ่นจากการอ่านการ์ตูนแทบจะล้วนๆ) ก็จะหาเรื่องทดลองใช้เลย ไม่ว่าจะเป็นการลองถามทางคนในรถไฟฟ้า การแกล้งหลงทางแล้วถามตำรวจ ฯลฯ ซึ่งมันได้ผลโคตรดี ถึงได้มีคนบอกว่า เวลาไปเรียนต่างประเทศ อยากจะเป็นภาษาเร็วๆ ต้องปิ๊งสาว (หรือเพศที่สนใจ อะไรก็ได้) สักคน เพราะเราจะต้องหาเรื่องใช้ภาษา ไม่ว่ารู้น้อยรู้มากแค่ไหนก็จะหาเรื่องสื่อสารตลอดเวลา แล้วมันจะเป็นเร็ว

ทีนี้เมื่อเริ่มสื่อสารเบื้องต้นได้แล้ว ความเข้าใจในภาษาที่ดีขึ้น ก็จะมีประโยชน์ที่ทำให้เราสื่อสารได้ดีขึ้น กระชับขึ้น สวยขึ้น กินใจขึ้น ฯลฯ หลายคำที่เคยใช้อย่างเวิ่นเว้อ ก็อาจจะใช้คำเฉพาะไปเลย อย่างเช่น ลองพยายามสื่อสารคำว่า “หึง” โดยที่เราไม่รู้จักคำนี้สิ จะพบว่ามันยากมาก แต่พอรู้แล้วการสื่อสารจะกระชับขึ้น ง่ายขึ้น และผิดพลาดน้อยลง

ซึ่งก็เหมือนกับการเขียนโปรแกรมน่ะแหละ ที่ตอนแรกไม่จำเป็นต้องรู้ตื้นลึกหนาบางอะไรของภาษาโปรแกรมที่ใช้มากมายนัก รู้แค่งูๆ ปลาๆ ก็เพียงพอแล้ว แต่จะต้อง “หัดสื่อสาร” ให้เร็วที่สุดและเยอะที่สุดเท่าที่จะเยอะได้

ตัวอย่างง่ายๆ ผมเชื่อว่าแทบทุกคนรู้จัก

printf("Hello, world\n");

(หรืออะไรก็ได้ที่เทียบเท่ากัน ซึ่งแตกต่างกันไปตามภาษา) ซึ่งมักจะได้เรียนกันในคลาสแรก ไม่ก็หนังสือบทแรก แต่จะมีกี่คนเชียวที่ “เล่น” กับมันต่อ เอาไปหัดสื่อสารมันต่อ ลองหาดูว่าจะประยุกต์หรือพลิกแพลงมันอย่างไรได้บ้าง เช่น จะลองให้แสดง

Name            Lastname        Sword
Byakuya         Kuchiki         Senbonsakura
Sousuke         Aizen           Kyokazuigetsu

โดยช่องว่างให้เว้นว่างทั้งหมด 2 Tab และให้ได้โดยใช้ printf เพียงตัวเดียว ทำได้หรือไม่ อย่างไร อะไรทำนองนี้

======================================

สรุปสั้นๆ การเขียนโปรแกรมก็เหมือนกับการสื่อสาร คิดว่าทำอย่างไรให้สื่อสารเก่ง ก็ทำแบบนั้นกับการเขียนโปรแกรม หลายคนอยากจะพูดภาษาอังกฤษเก่ง แต่เจอฝรั่งทีไรวิ่งหนีทุกที ให้พูดก็ไม่ยอมพูด แล้วมันจะเก่งได้อย่างไร ต่อให้วันๆ นั่งท่องไวยากรณ์ นั่งท่องศัพท์ ก็ไม่เคยมีประโยชน์ … พูดในฐานะคนที่พูดได้ 3 ภาษา ฟังออก 4 อ่านออก 6 ภาษา (แต่เป็นงูๆ ปลาๆ ไม่ค่อยแข็งแรงเท่าไหร่ซะ 3) นะครับ

บางครั้งเพื่อให้เก่งขึ้น เราอย่าเลือกพูดเฉพาะเรื่องที่เราอยากจะพูด เพราะบางทีมันจะยากเกินไป เช่น ถ้าเราเพิ่งจะเริ่มเรียนภาษาญี่ปุ่น จะไปคุยกับพวกบ้าการ์ตูนแถว Akihabara เลย ก็คงจะยากเกินไป(มาก)หน่อย แค่หัดถามทางเล็กๆ น้อยๆ สนุกๆ ให้ได้ก่อนจะดีกว่ามาก ประเด็นคือ ให้พูดๆ มันไปซะ อย่าคิดมาก อย่ากลัวผิดด้วย คนหัดภาษา พยายามพูด ผิดๆ ถูกๆ มีแต่คนเอ็นดู และจะช่วยเราทั้งนั้น

สุดท้ายคือ ให้ “ลงมือทำ” เพราะความ “อยากได้” มันไม่เคยมีประโยชน์เลย ถ้าไม่ “ลงมือทำ”

======================================

เรื่องสุดท้าย … แต่ก่อนอื่นต้องขอเล่าเรื่องตัวเองให้ฟังสักหน่อย ผมมีวิธีการเรียนเขียนโปรแกรมอยู่อย่างหนึ่ง ซึ่งโดยส่วนตัวแล้วมันเวิร์กสำหรับผม คือ

หัดให้ “มือ” เขียนโค้ด อย่า copy & paste เด็ดขาด และอย่าใช้สมองคิดโค้ดโดยไม่จำเป็น

เวลาผมจะหัดเขียนโปรแกรมในภาษาใหม่ และหัดจากหนังสือ ไม่ว่าจะเป็นหนังสือใครเขียน (และแน่นอน ว่าผมลองทำแบบนี้กับหนังสือตัวเองด้วย) ผมจะ “อ่านเนื้อหาผ่านๆ” ก่อน 1 เที่ยว จากนั้น “พิมพ์” โค้ดเหล่านั้นเองด้วย “มือตัวเอง” ผมจะไม่เคย copy & paste โค้ดในช่วงของการเรียนรู้เลย เพราะว่าสิ่งที่สำคัญที่สุดคือ มือผมต้องโค้ดเป็น

จากนั้น โค้ดมันจะใช้งานได้หรือไม่ได้ ไม่ต้องกังวล (ถ้าเป็นหนังสือผมเอง มักจะ “ใช้งานไม่ได้” ซะเป็นส่วนมาก เพราะหลายอย่างต้องเขียนเพิ่มเอง จากความรู้เก่า) ก็ถึงเวลาที่เราจะย้อนกลับไป “อ่านเนื้อหาอย่างละเอียด” อีก 1 เที่ยว พยายามทำความเข้าใจกับสิ่งที่มือมันเพิ่งจะโค้ดไป พยายามปรับปรุงแก้ไขจนมันใช้งานได้

ผลที่ได้จากการทำกระบวนการนี้ซ้ำแล้วซ้ำอีก ก็คือ มือผมจะโค้ดเองได้เสมอ เวลาต้องการอะไร มันแทบจะขยับเองอัตโนมัติ และสมองผมจะเป็นอิสระในการคิดกระบวนการ คิดลอจิก คิดท่าต่างๆ ที่จะใช้ในโปรแกรม

ซึ่งนี่คืออีกปัญหาที่ผมพบ ซึ่งเป็นปัญหา “ใหญ่ที่สุด” คือ ผู้ฝึกเขียนโปรแกรม ต้องการได้ผลลัพธ์สำเร็จรูปเร็วเกินไป ฉาบฉวยเกินไป ต้องการโค้ดที่เอาไป copy & paste ได้ กด compile & run เห็นผลลัพธ์ แล้วคนขยันหน่อย ก็อาจจะกลับมานั่งอ่านโค้ดบ้าง นอกนั้นก็ปล่อยๆ มันไป เพราะได้ผลแล้ว

ปัญหาที่ว่าน้ีก็คือ “โค้ดไม่เคยผ่านมือ” และ “ไม่ได้เป็นคนเริ่มเอง” (แต่เริ่มจากโปรเจคที่เสร็จแล้ว ที่คนอื่นเริ่มไว้ให้แล้ว) ซึ่งทำให้เวลาต้องทำงานจริงๆ จะเริ่มต้นอะไรเองไม่เป็นเลย และโค้ดเองไม่เป็นเลย มือมันจะไม่ขยับ และต้องไปเปลืองแรงสมองคิดโดยใช่เหตุถึงเรื่องโค้ด แล้วหลายคนก็จะ Blank .. ตายตรงนี้

ผมมีข้อสังเกต ว่าถึงระบบการศึกษาบ้านเรามันจะไม่ได้แย่ลงกว่าเดิมเท่าไหร่ แต่ทำไมคนเดี๋ยวนี้เขียนโปรแกรมแย่ลงกว่าเมื่อก่อนมาก ก็เพราะมันเริ่มต้น “ง่ายเกินไป” และ “ฉาบฉวยเกินไป” มีโค้ดอยู่แล้ว copy & paste ง่าย แค่ Ctrl+C, Ctrl+V ก็จบแล้ว หรือไม่ก็ download งานที่เสร็จแล้วมา unzip แล้วใช้งานได้เลย ดังนั้นโค้ดจะไม่ผ่านมือเลย ซึ่งนี่คือเรื่องที่หลายคนอาจมองว่ามัน “เล็กน้อย” แต่จริงๆ แล้วนี่คือเรื่องที่ “ใหญ่ที่สุด” เรื่องหนึ่ง

สมัยผมหัดเขียน C++ 98 (ที่เป็น Standard แรกที่มี STL) ผมซื้อหนังสือ The C++ Standard Template Library ของ Nicolai Josuttis มานั่งอ่านผ่านๆ ทั้งเล่มก่อน 1 เที่ยว และ “นั่งลอก” โค้ดทุกบรรทัดด้วยมือตัวเอง ทั้งเล่ม จากนั้นค่อยพยายามศึกษารายละเอียดอีกครั้งในเบื้องลึก

ซึ่งนี่เป็นวิธีเดียวกับที่ผมศึกษา Perl, Ruby, Objective-C, Mathametica, Haskell, OCaml, Scheme และภาษาอื่นๆ ที่ผมเขียนเป็น และเขียนพอเป็น

และนี่แหละ เป็นสาเหตุที่ผม “ไม่อยากให้โค้ด” สำหรับโปรแกรมจากหนังสือคู่มือเขียน iPhone App ของผม ซึ่งพิมพ์โดยสำนักพิมพ์ Provision

สรุปสั้นๆ: อยากเขียนโปรแกรมเก่ง ต้องหัด “เขียน” โปรแกรมครับ อย่าหัดแต่รันโปรแกรมที่คนอื่นเขียนแล้ว

======================================

หวังว่าคงจะเป็นประโยชน์บ้าง …​ จริงๆ แล้วเนื้อหาบทความนี้ คัดมาจาก “บทแรก” ของหนังสือเล่มใหม่ที่ผมกำลังเขียนอยู่ (ยังไม่มีชื่ออย่างเป็นทางการ แต่ประมาณ “คิดและโค้ด ผ่านภาษา Objective-C”) โดยดัดแปลงให้เหมาะกับการเป็นบทความบนเว็บ

รออ่านนะครับ ผมหวังว่าจะเป็นหนังสือที่ดี(นะ)

“Generation Click”

กลับบ้านคราวที่แล้ว นั่งคุยกับพ่อเรื่องน่าสนใจหลายเรื่อง เรื่องหนึ่งก็คือ เรื่องผู้ใช้คอมพิวเตอร์ ทั้งเป็นผู้ใช้แบบ user จริงๆ และนักคอมพิวเตอร์ นักเทคโนโลยีสารสนเทศและการสื่อสาร และโปรแกรมเมอร์ generation ใหม่ ที่พ่อผมเรียกว่า Generation Click

คุณพ่อบอกว่า “พวก Generation Click เนี่ย ไม่เจอ icon ไม่เจอเมนู ให้ click ได้ แล้วทำอะไรไม่เป็นเลย” แล้วอีกไม่นาน ก็ต่อด้วย “แบบนี้เขียนโปรแกรมใช้งานเองลำบากแย่เลย เพราะเขียนโปรแกรมจริงๆ ก็แค่เอาคำสั่งพวกนั้นมาต่อๆ กัน ไม่ใช่เหรอ?”

อืมมมมมม เห็นด้วยแฮะ

ก่อนจะพูดต่อไป ขอพูดถึงตัวเองหน่อย ….. ผมอาจจะโชคดีพอ ที่เกิดมาทันสมัย DOS (เครื่องแรกในชีวิต ที่ตั้งที่บ้าน ใช้งาน DOS 5.0 — ไม่มีเมาส์ด้วยซ้ำไป) ทำให้การทำงานกับ command line เป็นอะไรที่เป็นเรื่องปกติ รู้สึก at home กับมันมาก อยากจะให้มันทำอะไร ก็สั่งมันตรงๆ เป็นคำสั่งๆ ไป และแต่ละคำสั่งก็จะมี option อะไรก็ว่าไป ไม่พอ กว่าจะเล่นเกมได้แต่ละเกมๆ ก็ต้องแก้ config.sys, autoexec.bat กันวุ่นวาย ถึงขนาดต้องเขียน batch file เอาไว้เปลี่ยนสองไฟล์นี้เอง ด้วยความรำคาญ

พอชีวิตเริ่มเจอ GUI มากขึ้น ไม่ว่าจะเป็น Windows 3.x, Windows 95 ก็ได้ทุนไปเรียนญี่ปุ่น ก็พอเดินเข้าห้องคอมพิวเตอร์วันแรก ก็เจอ SGI IRIX เจอ GUI แบบไม่เคยเจอมาก่อน และต้องทำงานกับ Shell บน terminal emulator (ถ้าจำไม่ผิด รู้สึกว่าจะเป็น tcsh) ทำทุกอย่างบนนั้นหมด เหมือนกับเปลี่ยนโลกไปเยอะ จากนั้นเพื่อนๆ สนิทๆ กัน (Peter Suranyi, Janos Gyerik) ก็ยุให้เล่น Linux ก็เลยหามาลง ซึ่งก็กว่าจะหาทางทำให้ X-Windows มันทำงานได้ กว่าจะฯลฯ ได้ ก็แทบแย่

ประเด็นคือ การอยู่กับ terminal หรือ command prompt ทุกชนิดของผม ทำให้ผมมองการใช้งานคอมพิวเตอร์ เป็น “บทสนทนา” ระหว่างผมเอง กับคอมพิวเตอร์ ไม่ว่าผมจะใช้โปรแกรมอะไรก็ตามที่สามารถใช้งานในลักษณะ terminal ได้ จะเป็น MySQL, Octave, R หรือว่าโปรแกรมที่เป็น command line-based เช่น imagemagick ที่เอามาประกอบกับ shell scripting ได้ หรือว่า interactive programming environment ต่างๆ เช่น IRB, Python, Scheme, Haskell

กลับมาถึงบทสนทนาระหว่างผมกับคุณพ่อ

คุณพ่อผม เป็นนักปรับปรุงพันธ์พืช ที่ใช้ dBase 3 Plus ในการเก็บข้อมูล มานานมาก และเขียนโปรแกรมใช้งานเอง เริ่มจากใช้งานฐานข้อมูลนั้นๆ ทีละคำสั่งๆ แล้วก็เอาคำสั่งพวกนั้นมาต่อๆ กันเป็น routine/sub-routine และก็เริ่มซับซ้อนขึ้นเรื่อยๆ จนปัจจุบัน เป็นโปรแกรมที่มีความซับซ้อนมาก และทำงานได้ดี ช่วยงานได้เยอะมาก

สิ่งที่ท่านพบก็คือ นักปรับปรุงพันธ์รุ่นใหม่ ซึ่งใช้คอมพิวเตอร์ในการทำงานมากขึ้น ไม่ว่าจะในการวิเคราะห์ทางสถิติ หรือว่าการวิเคราะห์อื่นๆ กลับไม่ค่อยจะสามารถพัฒนากระบวนการคิดนั้นๆ ได้ และไม่สามารถที่จะมองความเชื่อมโยงระหว่าง process ระหว่างโปรแกรมได้เท่าไหร่ ไม่ต้องพูดถึงเรื่องเขียนโปรแกรมเลย ยิ่งกว่านั้น ในการทำงานทุกอย่าง จะมองหาแต่ icon ของคำสั่ง กระบวนการทำงานโดยทั่วไปคือ select & click และมองไม่ออกว่า จริงๆ สิ่งที่ทำๆ อยู่เนี่ยแหละ คือ “การสนทนา” ที่หากว่าบันทึกไว้ มันก็คือการเขียนโปรแกรมน่ะแหละ แต่พวกนี้กลับรักที่จะทำทุกอย่างแบบ manual แทน (เพราะว่าตัวเองได้เป็นคน click icon คำสั่งกระมัง)

มันเลยกลับมาถึงเรื่องที่ผมบ่นๆ ไว้บ่อยๆ เรื่องนักศึกษาในสาขาวิชาที่ต้องเรียนเขียนโปรแกรม ซึ่งพบว่า มีปัญหากับกระบวนการคิดค่อนข้างเยอะ และไม่สามารถคิดอะไรในลักษณะ “เอาคำสั่ง มาต่อกัน” หรือ chain ของ Input-Process-Output ได้เลย

ผมลองตั้งโจทย์คร่าวๆ ว่า “มีไฟล์อยู่หนึี่งไฟล์ ข้างในไฟล์มีคำอยู่เยอะ ซ้ำๆ กัน ผมอยากรู้ว่ามีคำไม่ซ้ำกันทั้งหมดกี่คำ?” (ทั้งนี้ คำทุกคำ เป็นตัวเล็กหมด และไม่มีอักขระแปลกๆ ตัวอย่างเนื้อความในไฟล์คือ this is a cat this is a bat this is a map this is a phone)

เชื่อหรือไม่ว่า ไม่มีนักศึกษาสามารถคิด logic ของโจทย์นี้ได้แบบเป็นขั้นเป็นตอน ชัดเจน ได้แม้แต่คนเดียว ใน class ที่ผมสอน! ทั้งๆ ที่ logic มันง่ายแสนจะง่าย ก็แค่

  • เปิดไฟล์ เอาเนื้อความ
  • เอาเนื้อความในไฟล์มา แยกเป็นคำๆ
  • เอาคำที่ได้ มากรองเอาคำซ้ำออก
  • นับคำที่เหลือ

จะเห็นว่า มันก็เป็น chain ของ I-P-O อยู่ชัดเจนนะ คือ สมมติว่ามันเป็นฟังคชัน f, g, h, i ตามลำดับ ก็จะได้ว่าคำตอบของมันก็คือ i(h(g(f(x)))) … เขียนให้มันง่ายๆ กว่านี้หน่อย สมมติว่าเป็นฟังคชันชื่อ readfile, splitwords, unique_element, count ตามลำดับ ก็เป็น count(unique_element(splitwords(readfile(“filename”)))) ใช่มั้่ย จากนั้นก็แค่เอาไปดูว่า แต่ละภาษาหรือ environment เนี่ย เอามาทำแบบนี้ยังไงดี มีฟังค์ชันมั้ย ต้องเขียนเองมั้ย ถ้าจะเขียนเองจะต้องเขียนยังไง ก็แค่คิด I-P-O แบบเดิม ลงไปให้ลึกขึ้น เท่านั้น

ถ้าเขียนใน bash shell ก็คงเป็น

cat filename.txt | tr " " "\n" | sort -u | wc -w

ถ้าเป็น ruby ก็เป็น

File.read("filename.txt").split(" ").uniq.count

ถ้าเป็น haskell ก็เป็น

content <- readFile "filename.txt"
length (List.nub (words content))

ซึ่งจะซับซ้อนกว่าตัวอื่นๆ นิดหน่อย เพราะว่ามีเรื่อง IO String กับ String มาเกี่ยวข้อง (purely functional ก็แบบนี้แหละ)

แถม ... เป็น C++ ก็ยาวหน่อย (ไม่รวมพวกการ include library มาใช้นะ)

int main()
{
  ifstream fin("filename.txt");
  set<string> words;
  copy(istream_iterator<string>(fin), istream_iterator<string>(),
       inserter(words, words.begin()));
  cout << words.size() << endl;
  return 0;
}

จะเห็นว่า logic มันไม่ได้เปลี่ยนเลยสักกะนิด เพียงแต่ว่าอาจจะ verbose บ้าง รูปแบบต่างกันบ้าง คำสั่งต่างกันบ้าง

วันนั้นข้อสรุปของบทสนทนาระหว่างผมกับพ่อก็คือ Generation Click พบความลำบากมากกว่า ในการคิดสื่อสารกับคอมพิวเตอร์เป็นขั้นตอน ด้วย text ด้วยคำสั่งต่างๆ ดังนั้นอาจจะช่วยได้ หากทุกคำสั่งมันมี icon หมด และลากมาวางต่อๆ กันได้ เหมือนกับ automator.app ใน Mac OS X หรือบรรดา visual programming ทั้งหลาย

สมัยผมสอน OOP ผมเคยให้ นักศึกษาเล่นกับ Alice ซึ่งก็เป็น visual programming พอสมควร ก็พบว่าได้ผลในระดับหนึ่ง แต่ว่าพอถึงเวลาต้องไปเขียน code ซึ่งเป็น text ก็ยังพบปัญหาเดิมๆ อยู่ เทอมนี้ก็เลยขอหักดิบ ให้ใช้งาน shell มันซะเลย เผื่ออะไรๆ จะดีขึ้นมาบ้าง

ลงท้ายด้วยการเผา advisee หน่อยละกัน ... เจอพวกที่แทนที่จะคิด logic ของระบบงาน กลับคิดแต่ว่าจะต้องใช้โปรแกรมอะไร ต้องเริ่ม click ที่ปุ่มไหน แล้วจะ click ปุ่มไหนต่อ งานถึงจะเสร็จ ....​ ฮา (ไม่ออก)

Real World Haskell และ รักแรกพบ

ไปเจอมา เอามา note ไว้สำหรับตัวเองและเพื่อนๆ พี่ๆ น้องๆ ทุกท่านที่สนใจ Haskell เป็นหนังสือที่ดีพอสมควรเลยทีเดียว ละเอียด ตัวอย่างเยอะ ค่อนข้างเป็นปัจจุบันมากๆ และมีประโยชน์กับ Real World จริงๆ (บ้างล่ะน่า) ไม่ใช่แบบหนังสือ Functional Programming ทั่วไปที่ยกว่า FP ดีอย่างนั้นอย่างนี้ แต่ว่าไม่ค่อยจะมีตัวอย่าง Real World ที่มัน convincing เท่าไหร่เลย ยกแต่ประโยชน์ที่ … ขอโทษนะ ต้องบอกว่า “ถ้าไม่ได้เขียน FP เป็นอยู่แล้ว ก็คงจะไม่ซึ้งกับมันเท่าไหร่ ว่ามันเจ๋งแค่ไหน” มากกว่า

แปะลิงค์ก่อน

Real World Haskell (beta) by Bryan O’Sullivan, Don Stewart, and John Goerzen

Haskell เป็นภาษาโปรแกรมที่ผมชอบมากที่สุดภาษาหนึ่งเลยก็ว่าได้ นอกจากนี้ยังเป็นสิ่งแรกในโลกที่สอนให้ผมรู้จักและเข้าใจความรู้สึกของคำว่า “รักแรกพบ” ด้วย

เรื่องของเรื่องมันมีอยู่ว่า วันนั้นนั่งเขียนโปรแกรมอะไรซักอย่างอยู่ในห้องคอมพิวเตอร์ที่มหาวิทยาลัย Tsukuba (ไม่ได้เขียนอะไรใหญ่โตหรอก รู้สึกจะหัดเขียนพวก data structures เล่นอยู่) แล้วเพื่อนสนิทมากที่สุดคนหนึ่ง ชื่อ Nao Hirokawa (จริงๆ แล้วเป็นรุ่นพี่) ก็เดินเข้ามา แล้วก็ชวนคุยเล่นกันโน่นนี่ พอเห็นที่เราเขียนเล่นอยู่ ก็ถามว่า “เฮ้ ทำไมไม่ใช้ Haskell?” เราก็เลยถามว่า มันคืออะไรหว่า Hirokawa ก็เลยถามว่า รู้จัก Quick Sort มั้ย แหม ใครจะไม่รู้จัก เค้าก็เขียน Quick Sort เป็น Haskell ให้ดู พร้อมกับที่เราอ้าปากค้างตาโต (โดนแหก — จริงๆ แล้วรู้สึกว่า Quick Sort นี่เป็นตัวอย่างตลาดของ Haskell เลยนะ .. คงไม่มีใครไม่ยกตัวอย่างอันนี้มาแหกตาชาวบ้านเวลาโชว์ Haskell) แล้วก็เล่น List Comprehension ให้ดูอีกนิดๆ หน่อยๆ

นั่นแหละ รักแรกพบครั้งแรกในชีวิต

Lambda และ Closures ใน C++0x

ในที่สุดสิ่งที่รอมานานกับภาษาแรกๆ ที่หัดเขียนโปรแกรมก็เป็นจริงซะที หลังจากที่มันพยายามทำตัวเป็น Functional language แบบห่วยๆ (ลูกผีลูกคนเกินไป) มานานแล้วตั้งแต่ STL ….

C++ and Lambda Function Tradeoff: Clutter vs. Expressiveness (จาก Beautiful Code)

ช่วงนี้ภาษาหลายภาษาเริ่ม propose การเอาความสามารถของภาษาตระกูล Functional (พวก Lisp, Haskell) เช่น Lambda expression เข้ามาเป็นส่วนหนึ่งของภาษามากขึ้น ซึ่งหลายภาษาทำแล้วก็ดูดีขึ้น เลยทำให้เรามีความคาดหวังสูงพอควรกับภาษา C++0x ล่ะมั้ง

แต่ว่าพออ่านจาก ISO C++ Standards Meeting report …. โอ้ว แม่เจ้า ทำไมมัน clutter ได้ขนาดนั้น แบบนี้ไม่ค่อยจะปลื้มเลยนะเนี่ย

ผมคิดมาตั้งนานแล้ว ว่าข้อเสียที่ใหญ่ที่สุดของ C++ มันคือสิ่งที่มันพยายามให้เป็นข้อดีที่สุดน่ะแหละ คือการเป็น multi-paradigm language โดยที่ไม่มี paradigm ไหน dominant เท่าไหร่

ผลที่ตามมาน่ะเหรอครับ? ทุกวันนี้หลายคนก็ยังเขียน C++ แบบ C/Pascal หลายคนก็ยังเขียน OOP กับ C++ ไม่เป็น OOP ฯลฯ ไม่พอ ตอนที่ STL เริ่มจะมีความสามารถแบบ Functional ตลอดจนการมี Function Object และฟีเจอร์อื่นๆ อีกมากมาย ทำให้มีผลอย่างหนึ่งคือ การเขียนโปรแกรมเพื่อทำงานอย่างหนึ่งใน C++ เนี่ย มันทำได้หลายแบบเกินไป…. ถ้าเป็นหลายแบบใน paradigm เดียวกันคงจะไม่เป็นไรเท่าไหร่ แต่ว่านี่มันหลายแบบในหลาย paradigm

แบบนี้สับสนตายชัก และนับวัน C++ ก็จะมี identity crisis มากขึ้นทั้งที่มันไม่ควรเป็นแบบนั้น

เสียดาย…​เสียดาย

เท่าที่ดูผ่านๆ จากตัวอย่าง ถ้าให้ผมเลือกระหว่างการใช้ Lambda expression ใน C++0x กับเลือกใช้ Function object ผมคงจะเลือกอย่างหลัง ….​ เพราะว่ามันยังอ่านง่ายกว่า code มันสวยกว่า (สะอาดกว่า) ทั้งๆ ที่ใจชอบ Lambda มากกว่า (ใช้มันทุกภาษา…. ถ้ามีให้ใช้ …​และแล้วก็คงจะเจอข้อยกเว้นจนได้ — ถ้าวันนั้นยังเขียน C++ อยู่นะ)

การใข้ Header Files ของ Standard C++

หมายเหตุ

  • บทความนี้เขียนครั้งแรกใน blog วิชา 517211 Programming Languages และเอามาลงใหม่ที่นี่อีกที
  • บทความนี้เกี่ยวข้องกับ Standard Library Headers ของ C/C++ เท่านั้น ไม่เกี่ยวข้องกับ Non-standard Library (เช่น conio.h หรือว่า library อื่นๆ ที่ download มาใช้เอง เช่นพวก image processing หรือว่า XML แต่อย่างใด)

ใน C++ (ตั้งแต่ C++98) เนี่ย header มันเปลี่ยนจาก .h เป็นไม่มี .h แทน เช่น iostream.h ก็เป็น iostream นอกจากนี้แล้วยังมีอีกเรื่อง คือ headers ทั้งหลายที่มาจาก C ซึ่งเปลี่ยนจาก .h เป็นใช้ c นำหน้า เช่น stdio.h เป็น cstdio แทน

โดยทุกอย่างที่อยู่ใน C++ standard library นี้จะอยู่ใน namespace ที่ชื่อ std ซึ่ง namespace ก็คือ ที่สำหรับเก็บชื่อ ว่่าชื่อนี้เป็นของอะไร เช่น std::cin คือ cin ที่อยู่ใน std เป็นต้น

ทีนี้ก็เลยกลายเป็นสาเหตุเล็กๆ น้อยๆ ที่เราควรจะสนใจและใช้ header ให้มันถูกต้องเสียที เวลาที่เขียน C++

  • ความเก่าและใหม่ เพราะว่า C++ บาง implementation ยังคงเก็บ .h headers ไว้เพื่อให้ compatible กับ code เก่าเท่านั้น (คือให้ code เก่าที่เคยเขียนมาสมัย pre-standard ยังคง compile ได้เท่านั้น) จะไม่มีการ update ให้ใช้ความสามารถใหม่ๆ ได้แต่อย่างใด

    ลองคิดว่าเป็นอารมณ์เดียวกับที่ Microsoft เลิก update Windows 98 ไปนานแล้ว …. แต่ว่าคุณยังเก็บ Win98 อยู่ เพราะว่ายังมีบางโปรแกรมที่ยังคงใช้มันอยู่ และใช้บน XP ไม่ได้น่ะแหละ

  • namespace พูดเป็นเล่นครับ นี่เรื่องใหญ่กว่าที่หลายๆ คนคิด ใครที่เคยเขียน C/C++ จะเข้าใจดี เรื่องความซ้ำกันของชื่อฟังค์ชัน หรือว่าชื่อ constant ต่างๆ เป็นปัญหาหลัก เนื่องจากว่ามันมีซ้ำไม่ได้เด็ดขาด (ห้ามประกาศซ้ำ ในหนึ่งโปรแกรม) สมมติว่าผมใช้ library บางตัว และมี function ที่ชื่อซ้ำกับ standard library หรือว่าซ้ำกันเองระหว่าง library อื่นๆ นี่จบกันเลย ต้องแก้โน่นแก้นี่เยอะมาก

    ทีนี้เป็นเรื่องครับ เพราะว่า standard library ของ C++ นั้นค่อนข้างจะใหญ่พอควร และมีชื่อที่ค่อนข้างโหลอยู่มากมาย เช่น vector (ใน header ชื่อ vector) หรือว่า max, find, count (ใน algorithm) เป็นต้น การที่พวกนี้อยู่ใน namespace std จะช่วยป้องกันปัญหาชื่อซ้ำกันได้บ้าง (เยอะเลยแหละ) เพราะว่าปกติชื่อมันจะไม่ซ้ำกันข้าม namespace

    ปัญหานี้มันก็อารมณ์เดียวกับคนชื่อซ้ำๆ กันในคณะ (เช่น ชื่อ ฝน หรือว่า เมย์ … ชื่ออะไรดีที่มีเยอะๆ?) แต่ว่าถ้าบอกว่า ฝน เอกคอมพ์ นี่คงจะน้อยลงไปเยอะเลย (โอกาสซ้ำกันก็ยังพอมีอยู่ แต่ว่าสำหรับ std namespace แล้วการันตีว่าไม่มีการซ้ำภายใน namespace เดียวกัน) .. งั้นการบอกว่า std::max ก็เหมือนกับบอกว่า เอกคอมพ์::ฝน น่ะแหละ … แต่ว่าถ้าชื่อไม่ค่อยจะโหล เช่น เอิง อะไรแบบนี้ก็แล้วไป (ถ้าเป็น C++ ก็คงจะพวก bind2nd อะไรทำนองล่ะมั้ง)

  • เรื่องความเข้ากันได้ของ C และ C++ เอง …. เรื่องนี้ไม่น่ามีล่ะครับ แต่ว่าก็ว่าไม่ได้ เพราะว่าไม่มีใครกำหนดไว้ชัดเจน แต่ว่าเนื่องจาก C และ C++ เอง นับวันก็ยิ่งจะแตกต่างกันในเรื่องของรายละเอียดเล็กๆ น้อยๆ มากขึ้นๆ เรื่อยๆ ถ้าเราใช้ .h library เมื่อไหร่ นั่นหมายถึงเราอาจจะใช้ library ของ C อย่างไม่รู้ตัวครับ นั่นแปลว่า ถึงเราจะแม่น devils in details ของ C++ มากแค่ไหน แต่ว่าถ้าเราใช้ของ C โดยที่เราคิดว่าใช้ของ C++ อยู่ล่ะ? ….. เราจะเจอปัญหาเล็กน้อยพอควรทีเดียว และเราจะไม่คิดด้วย ว่ามันเป็นปัญหาที่จุดนี้

    เรียกว่าถ้าเราจะใช้ C ก็ใช้ .h ให้ชัดเจน แต่ว่าถ้าจะใช้ C++ ก็เอา .h ออก และใช้ c ขึ้นหน้า (เช่น cstdio, cstdlib, cstring, cctype เป็นต้น)

    อ่อ ….​ และถึงตรงนี้เลยฝากไว้นิดเลยละกัน ว่า string.h ของ C (ที่มีพวก strlen) มันจะกลายเป็น cstring ใน C++ นะครับ ถ้า string ของ C++ จะเป็นอีกตัวนึง ซึ่งเป็นคนละเรื่องกันเลย

คงเป็นความรู้ประกอบการตัดสินใจในการเลือกใช้ header สำหรับการเขียน C/C++ ได้บ้างครับ

ภาษาโปรเกรียน

โอ๊ย อ่านแล้วขำสุดๆ กลิ้งไปกลิ้งมา

สุดยอดมาก ยกนิ้วโป้งให้สองนิ้วเลย

สรุปให้นิด ว่าทำเหมือนกับว่าภาษาโปรแกรมแต่ละภาษาเป็นคน แล้วเอาข้อดีจริงๆ หรือว่า hype หรือว่า buzz ของตัวเองมาข่มกันไปมา แถมมีการแขวะกันแบบตลกร้ายมากๆ ด้วย ชอบตรงนี้น่ะ

Ruby: Dude! I just wrote a full working clone of Google while you were giving your riveting little speech there! (โอ๊ย ระหว่างที่พวกเอ็งโม้กันอยู่เนี่ย ข้าเขียน Google clone เสร็จแล้วนะเฟ้ย)

Moderator: Oh, bravo, Ruby! I’d like to see that. Where is it deployed? (เจ๋งมากรูบี้! ขอดูได้มั้ย เอาไปติดตั้งไว้ที่ไหนเหรอ?)

Ruby: Umm…. (เอ่อ…..)

จริงๆ ขำทั้งเรื่องน่ะแหละ สุดๆ

สับสน … ชื่อภาษาโปรแกรม?

ช่วงนี้ตรวจข้อสอบเด็กเยอะแยะ ตาลาย ไม่พอ ยังไม่วายเข้าไปดูตาม webboard หลายที่ …​ ก็เจอเรื่องที่คาใจมาน้านนาน คือ มักที่จะเจอคนเรียก IDE หรือ Editor ปนกับชื่อภาษาโปรแกรม โดยเฉพพาะเมื่อตัว IDE นั้นๆ มันดันมีชื่อภาษาปนอยู่ด้วย เช่น

  • ภาษา Turbo C
  • ภาษา Dev-C++
  • ภาษา Visual C++
  • ภาษา RadRails
  • ยังมีอีก ฯลฯ

ซึ่งอ่านไปอ่านมาก็ตลกดี คิดในบางแง่มันก็อาจจะ make sense เนื่องจาก

  • ภาษาหลายภาษา (เช่น C, C++) เป็นเพียงแค่ข้อตกลง ข้อกำหนด เท่านั้น บางอย่างก็จะเป็น vendor-specific โดยเฉพาะในจุดที่ไม่นิยามในตัวข้อกำหนดมาตรฐานจริงๆ (undefined by standard) ซึ่งจะทำให้ภาษาเหล่านี้แตกต่างกันไปตาม vendor
  • Vendor หลายเจ้า โดยเฉพาะ Microsoft มักจะมีปัญหาประจำแหละ เรื่องนี้ คือไม่ได้ implement C++ ของตัวเองตามมาตรฐานของ C++ เสียทีเดียว อะไรหลายๆ อย่างที่มันถูกต้องตาม standard C++ ก็ไม่ถูกใน C++ ของ Microsoft
  • บางทีมันก็เป็นเรื่องของ library ด้วย คือ vendor หลายเจ้ามักจะ implement อะไรหลายๆ อย่างเพิ่มเข้าไปจากที่จำเป็นต้องมีอยู่แล้วใน standard library (ถ้าเป็น C ล่ะก็ ตัวยอดนิยมคงจะไม่พ้น itoa() ใน stdlib.h กระมัง)

แต่ว่ายังไงๆ ก็ตาม เราก็น่าจะเรียกตามชื่อ vendor ของมันมากกว่าจะเรียกตามชื่อ IDE ไม่ชื่อหรือ ไอ้พวก “ภาษา ​Turbo C” นี่คงไม่เท่าไหร่ เพราะว่า implementation ของ C ตามแบบนั้น คงจะไม่มีคนทำ IDE ขี้นมาใช้นอกจาก Turbo C เอง (แต่ว่าก็ไม่แน่ เพราะว่าจริงๆ ก็สามารถทำ modern IDE ขึ้นมาเรียกการทำงานของส่วน compiler ใน Turbo C ก็ได้)จริงๆ แล้ว Borland ก็มี compiler สำหรับ Windows นะ ให้ใช้งานได้ฟรีๆ นะ แต่ว่าเป็น command line ซึ่งจำเป็นต้องหา IDE มาครอบใช้งานเอง (เช่น JFE หรือ CPad ผมเคยใช้แต่ตัวหลัง ตัวแรกลองแล้วไม่ค่อยชอบ) โดยสำหรับตัว compiler ตัวนี้ผมเข้าใจว่าตัวนี้เป็น compiler ตัวเดียวกับที่ใช้ใน C++ Builder แต่ว่าไม่แน่ใจ เพราะว่าไม่มี C++ Builder แต่ว่านั่นแหละ ถ้าเป็นตัวเดียวกันจริง ก็จะมีคนเรียกมันว่า “ภาษา C++ Builder” แทนที่จะเป็น “ภาษา C++ ของ Borland” (Borland’s implementation of C++)เช่นเดียวกับการเรียก “ภาษา Visual C++” แทนการเรียก “ภาษา C++ ของ Microsoft” (Microsoft’s implementation of C++)แต่ว่าเจ้า “ภาษา Dev-C++” นี่สิ เรื่องใหญ่ ทั้งๆ ที่เรียกใช้งาน GNU GCC ซึ่งเป็น GNU’s implementation of C/C++ นะ … Misleading มากเลย

Pointless Programming : Java 7

จริงๆ เค้าเรียกว่า Point-Free Programming (HaskellWiki) หรือว่า Tacit Programming (Wikipedia) นะ :-P ผมเขียนชื่อล้อเลียนไปงั้นเอง เรื่องนิยามหรือว่าตัวอย่างลองไปดูใน Wiki link ด้านบนเอานะครับ แต่ว่าผลของมันเนี่ย มันมักจะทำให้โปรแกรมสั้นขึ้น ในขณะที่มันก็ยังอ่านง่ายขึ้นด้วยเออสิ แล้วมันเกี่ยวอะไรกับ Java 7 ล่ะเนี่ย? เพราะว่าใน spec ของ Java 7 มันจะมีเรื่อง Closures เข้ามาเกี่ยวข้องด้วย แล้วก็จะมีเรื่องอื่นๆ ที่เอา idea จาก Functional programming มายัดลงไปในภาษาที่มันค่อนข้างจะ bloat และ verbose ที่สุดภาษานึง ทำให้มันสั้นลง กระชับขึ้น น่าอ่านน่าเขียนขึ้นแบบไม่น่าเชื่อ ลองดูตาม Link ต่อไปนี้นะครับ

ส่วนนิยามของ Closures ในแบบ Computer Science และ Software Development จริงๆ ก็ตามนี้ครับ Closure (computer science) – Wikipediaขอปิดท้าย post นี้ด้วยเรื่องของ Point-Free Programming ใน Java 7 ครับ สวยดีเหมือนกัน ดูรายละเอียดเต็มๆ ที่นี่: Ricky’s technical blog: Point-free Programming in Java 7 – Beyond Closuresผมว่าโลกมันกำลังหมุนไปในทิศทางที่มันถูกต้องนะ ที่ในที่สุดก็เริ่มจะมีการเอา idea ของ Functional programming มาใช้ในภาษาโปรแกรมที่เป็น mainstream เสียที เพราะว่า programming model ของ Functional มัน elegance กว่า imperative เยอะมาก …สุดท้ายมันทำให้ผมนึกถึง paper ที่เป็น hall-mark สุดยอดอันนึงของ John Backus (ผมเคยเขียนถึงเรื่องเค้าทีนึงที่ Thai Mac Dev นะ) คือCan programming be liberated from the von Neumann style?: a functional style and its algebra of programs (Link ไปหา paper ที่ Stanford University)เมื่อ Java 7 ออกมาจริงๆ ผมคงจะต้องกลับมามองมันแบบ serious อีกที แต่ว่าเราก็ไม่รู้เหมือนกัน ว่าวันนั้นโลกมันจะหมุนไปถึงไหน และจะมี feature อะไรอีกบ้าง ใน niche programming languages ที่ทำให้ผมอ้าปากค้าง ตกหลุมรัก และมอง Java 7 “ในวันนั้น” ว่ามันไม่ elegance ….. อย่างว่าแหละครับ Programmers Don’t Like to Code ;-)

เปลี่ยนภาษาเขียนโปรแกรม

อะไรยากกว่ากัน ระหว่าง

  1. สอนคนที่เขียนโปรแกรมเป็นแล้ว ให้เปลี่ยนภาษา
  2. สอนคนที่เขียนโปรแกรมไม่เป็น ให้เขียนโปรแกรมเป็น

หลายคนจะตอบข้อ 2 โดยไม่ลังเลเท่าไหร่ เพราะว่าถ้าเป็นภาษาหนึ่งๆ แล้ว เรียนอีกภาษาหนึ่งคงไม่ยากเท่าไหร่ สาเหตุหนึ่งก็คงเพราะว่าภาษาส่วนมากมีรากที่คล้ายๆ กัน เช่น Pascal, C, C++, Java, C# ถ้าเป็นภาษาใดภาษาหนึ่งแล้ว การเรียนรู้ syntax ของอีกภาษาหนึ่งก็ไม่ใช่เรื่องยากเย็นเท่าไหร่แต่ว่าสอนคนที่เขียนโปรแกรมไม่เป็นให้เขียนโปรแกรมเป็นนี่สิ งานช้าง เพราะว่าอาจจะต้องสอนแนวคิด หลักการคิดแบบคอมพิวเตอร์ หลักการคิดแบบ von Neumann machine หลักการคิดแบบที่เราต้องใช้เวลาเขียนโปรแกรม ฯลฯ ซึ่งอาจจะยากหน่อย ไหนเลยจะต้องมานั่งเรียนรู้ syntax อีกแต่ว่าถ้าเปลี่ยนคำถามหน่อยนึงล่ะ เปลี่ยนข้อที่ 1 ให้เป็น

  1. สอนคนที่เขียนโปรแกรมเป็นแล้ว ให้เปลี่ยน paradigm ในการเขียนโปรแกรม

ไอ้นี่อาจจะเป็นงานช้างพอๆ กัน หรือว่าช้างกว่าการสอนคนที่เขียนโปรแกรมไม่เป็นให้เขียนโปรแกรมก็ได้ เพราะว่าคนเราพอมันชินกับวิธีคิดแบบไหนแล้ว การจะเปลี่ยนรูปแบบของวิธีคิด การที่จะออกจาก The Matrix ของกระบวนการคิดของตัวเอง หรือว่าลักษณะการคิดของตัวเองได้ นี่คงจะยากเย็นแสนเข็ญมิใช่น้อย จะยกตัวอย่างดังนี้

  • นึกถึงโปรแกรมที่ประกาศตัวแปรไม่ต้องประกาศ type แต่ว่าก็ยังเป็น strong typing ออกไหม
  • นึกถึงโปรแกรมที่ไม่ต้องประกาศ main function ออกไหม
  • นึกถึงภาษาโปรแกรมที่ไม่มี loop ออกไหม
  • นึกถึงภาษาโปรแกรมที่ฉลาดพอที่จะทำ list comprehension (เช่นบอกว่า จะเอา x จาก list L โดยที่ x มากกว่า 3 แล้วมันเข้าใจว่าจะต้องทำอะไรโดยที่เราไม่ต้องเขียน low-level instruction)

นอกจากเรื่องพวกนี้จะยาก เพราะว่าพอสมองเราถูก over-train ให้ชินกับอะไรบางอย่างมากๆ แล้ว มันจะเรียนรู้สิ่งใหม่ยากขึ้น มีอะไรที่ต้อง unlearn มากขึ้น อย่าว่าแต่ imperative vs. functional programming เลย แค่ procedural vs. object-oriented ก็แย่แล้ว การที่เราจะ unlearn เรื่องหนึ่งๆ แล้วปรับไปสู่เรื่องใหม่ เป็นเรื่องที่ค่อนข้างยากเอาการทีเดียวไม่ใช่แค่นั้น แต่ให้เขียน style เดิม แต่ว่าเปลี่ยนภาษาเขียนโปรแกรม ก็ยากแล้ว

  1. สอนคนที่เขียนโปรแกรมเป็นแล้ว ให้เปลี่ยนภาษา โดยต้องใช้เป็นภาษาหลักในกรณีทั่วไปแทนภาษาเดิม

ผมเห็นน้องหลายคนเขียน Ruby กันมาพักนึง (เพราะว่างานบางงานที่อาจจะต้องใช้ Rails) แต่ว่าพอลองตั้งโจทย์ที่มองไม่เห็นชัดว่าจะใช้ความสามารถของภาษาตรงไหน (ให้สร้าง permutation ของ list) น้องหลายคนก็ fall-back กลับไปเขียน C เหมือนเดิมไม่แปลกอะไร เพราะว่าจริงๆ แล้วผมเอง บางทีขนาดโปรแกรมง่ายๆ ก็ยังดื้อจะเขียน C++ กับ STL อยู่เลย ทั้งๆ ที่รู้อยู่แก่ใจว่า Ruby, Python, Haskell มันก็ทำได้ และจะง่ายกว่าด้วย แต่ว่าทำไมนะ ทำไมผมถึงยังจะดื้อที่จะ fall-back ไปเขียน C++ อยู่ดี?ความเคยชินบางอย่างมันแก้กันยาก อาจจะเป็นเพราะว่าผมใช้เวลาอยู่กับ C++ มานานกว่าภาษาอื่นๆ และทำงานจริงในภาษาตระกูล C มานานกว่าภาษาอื่นๆ หลายเท่าตัวก็ได้ (C, C++, Objective-C)เปล่าหรอกครับ ผมไม่ได้ถามเพื่อหาคำตอบใดๆ เพราะว่านี่คือธรรมชาติของมนุษย์ อะไรก็ตามที่เราทำจนเป็นนิสัย จนเป็น second nature แล้วมันอาจจะเปลี่ยนแปลงยากมาก หลายเรื่องเราเปลียนไม่ได้ เพราะว่าเรามีความรู้สึกว่า “เคยทำ” อะไรที่มันคล้ายๆ กันมาก่อนในลักษณะนั้นอยู่แล้ว (เช่นเวลาผมจะเขียนโปรแกรมง่ายๆ บางทีผมใช้ C++ โดยไม่มีเหตุผล ทั้งๆ ที่เขียน Ruby ง่ายกว่าเยอะ ส่วนหนึ่งเพราะว่าผม “เคยทำ” สิ่งนั้นมาแล้วใน C++ มั้ง)ผมเลยมีข้อสังเกตและข้อเสนอแนะให้น้องๆ ที่อยากจะเขียนโปรแกรมภาษาใหม่นะครับ ดังนี้

  1. เขียน code ภาษานั้นให้เยอะที่สุดและเร็วที่สุด โดยอย่าเอาแต่ลอก code จากหนังสือหรือว่า tutorial เพราะว่าคุณจะไม่ได้ใช้งานจริง และไม่ได้ force ให้ตัวเองคิดในลักษณะของภาษาใหม่ๆ เท่าไหร่
  2. เรียน standard library ของภาษานั้นๆ ให้มากที่สุดในเวลาที่น้อยที่สุด เพื่อให้รู้ว่ามันพอจะทำอะไรให้เราได้บ้าง โดยไม่ต้องลงอะไรเพิ่มเติม แล้วก็ลองดูว่ามันเอามาทำอะไรให้ชีวิตเราง่ายขึ้นได้บ้าง
  3. หักดิบ อย่าเล่นภาษาเดิมเท่าที่จะทำได้ ถ้าจำเป็นจริงๆ ก็ลองลบ compiler ภาษาเดิมทิ้งไปเลย
  4. อย่าเอาแต่เรียน syntax กับ library นะ เพราะว่าสิ่งที่สำคัญที่สุดสิ่งหนึ่งที่แทบทุกคนลืม ก็คือ การเรียน idiom ของภาษานั้นๆ ยิ่งหลายภาษา โดยเฉพาะพวกภาษาใหม่ๆ เป็นพวก expressionism ซะด้วยสิ แบบนี้ idiom ยิ่งสำคัญมากเข้าไปอีก
  5. ยิ่งถ้าเป็นการเรียนภาษาคนละ paradigm กับที่เคยเขียนนะ ยิ่งไปกันใหญ่ เพราะว่าลักษณะการเขียน วิธีคิด idioms ต่างๆ มันจะต่างกันมาก มากๆ ถึงมากที่สุด
  6. ยากนะ แต่ว่าหลายครั้งต้องคิดนอกกรอบเดิม ถ้าคิดตามกรอบเดิมล่ะก็ คุณก็จะไม่ได้เขียนภาษาใหม่หรอก แต่ว่าจะเขียนภาษาเดิมน่ะแหละ แต่ว่าอยู่ใน syntax ใหม่เท่านั้นเอง
  7. ทำงานจริง เพราะว่าทำงานจริงเท่านั้นที่จะบังคับให้เราต้องอยู่กับภาษาโปรแกรมภาษาใหม่และกระบวนการคิดของมัน ยิ่งทำงานจริงแบบมี deadline ด้วยแล้วล่ะก็ ยิ่งดี เพราะว่าเป็นการบังคับให้เรายิ่งต้องคิดและ figure out การทำงานต่างๆ และ idioms ของมันให้ได้เยอะที่สุด เพื่อประโยชน์สูงสุด และให้งานเสร็จเร็วที่สุด
  8. หา library เพื่อช่วยงานโน้นงานนี้เยอะๆ มีของเล่นเยอะๆ แล้วลองเล่นกับมัน เดี๋ยวก็ชินกับมันไปเองแหละ
  9. ดูภาษาอื่นๆ ใน paradigm เดียวกันบ้าง เพื่อหาข้อเปรียบเทียบหน่อยๆ ก็ดี
  10. ระลึกไว้ ว่าไม่ใช่ทุกภาษาเหมือนกัน สิ่งที่ผิดหลักการในภาษาหนึ่ง อาจจะเป็นสิ่งที่ถูกหลักการและควรทำในอีกภาษาหนึ่งก็เป็นได้ ดังนั้นอย่ายึดติดกับหลักการและข้อบังคับข้อกำหนดต่างๆ ของภาษาหนึ่งๆ มากไปนัก
  11. พยายามมองหาโอกาสใช้มันให้เยอะที่สุดเท่าที่จะทำได้ และอย่าเลี่ยงโอกาสในการใช้มันซะล่ะ

จริงๆ เรื่องนี้ยังเขียนได้อีกยาวมาก แต่ว่าวันนี้พอแค่นี้ก่อน ชักเหนื่อย แต่ขอปิดท้ายด้วย quote ดังจากคนดัง

Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.Marvin Minsky