GNUstep 1.6, 1.8 LiveCD

อ่านจาก OSnews เรื่องข่าว 1.6 LiveCD ไม่ทันไรก็มีข่าว 1.8 LiveCD อีก

รู้สึกว่าช่วงนี้จะ active มากหน่อยนะเนี่ย …. เคยชอบมากเลย project นี้ แต่ว่าพอเปลี่ยนจาก Linux มาเป็น OS X แล้วก็ไม่ค่อยได้เล่นเท่าไหร่ รู้สึกว่าครั้งสุดท้ายที่ลองเล่นนี่ชาตินึงแล้วมากๆ

รู้สึกดีจัง กับ project ที่เราเคยชอบมากๆ … แต่ว่าด้วยอะไรหลายๆ อย่างทำให้ต้องเลิกเล่นไป แล้้วก็ไม่ได้ contribute อะไรเลย (แม้แต่ code ซักบรรทัด — เคยคิดว่าจะทำ app ไปลง GNUstep เหมือนกัน …​แต่ว่าไม่ล่ะ ตอนนี้อยากลองเขียนลง iPhone มากกว่า)

วันนี้กลับออฟฟิชเมื่อไหร่ จะลองเล่นดูครับ

การใข้ 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++ ได้บ้างครับ

Ruby 1.9-dev released!

Ruby > Ruby 1.9.0 is released ของขวัญ Christmas จาก Matz!

รอคอยกันมานาน กับ Ruby 1.9 ซึ่งเป็น major release แรกหลังจาก 1.8 ออกมานานแล้ว ซึ่งใน version นี้จะมีอะไรหลายๆ อย่างเพิ่มเข้ามา โดยเฉพาะที่หลายๆ คนรอคอยกัน ก็คือประสิทธิภาพที่เพิ่มขึ้น ความเร็วที่เพิ่มขึ้น

  • เนื่องจากมันเป็น development release ดังนั้นมันจะยังไม่ stable นะครับ (จาก message ของ Matz เองใน ruby-forum.com

    We couldn’t make it error free, but it’s fairly good, we hope.

  • ใครที่ใช้ Ruby on Rails เป็นหลัก อย่าเพิ่ง ลงเด็ดขาดครับ เพราะว่ามันยังไม่ compatible กัน ทาง Rails จะยังต้องเปลี่ยนโน่นเปลี่ยนนี่เยอะเหมือนกันนะ (อันนี้ผมไม่ confirm ครับ เพราะว่าผมยังไม่ได้ลองดู Ruby 1.9 และภายในของ Rails ละเอียดพอที่จะให้ comment อะไรได้) แต่ว่าก็มีคนศึกษาเรื่องนี้เหมือนกัน เช่นที่ eigenclass เป็นต้น
  • ในขณะที่ประสิทธิภาพสูงขึ้นพอควรจาก benchmark ต่างๆ นั้น … ประสิทธิภาพกับ Rails (เท่าที่ test ได้) กลับไม่ดีขึ้นเท่าที่ควร (และแย่ลงด้วยในบางกรณี)

ร้องเพลงรอกันไปนิดดีกว่าครับ แต่ว่าถ้าใครมีเวลาก็ลองเล่นดูก็ดีครับ เพราะว่าไม่ช้าก็เร็ว เราก็ต้องเจอกับมันอยู่แล้ว

รวมปัญหาเรื่อง lib ใน Leopard

ตอนนี้เริ่มเล่น Leopard ในฐานะของนักพัฒนาโปรแกรมและพวกชอบงัดแงะมากขึ้น และตอนนี้เท่าที่ลองเล่นก็เจอปัญหาโน่นนี่นิดหน่อย ซึ่งได้ post ไว้ใน ThaiMacDev เรื่อยๆ แต่ว่าขอรวบรวมไว้ตรงนี้อีกที่หนึ่งละกัน

ไว้เจอมากกว่านี้แล้วจะ post ไว้เรื่อยๆ ครับ

เริ่มเขียนโปรแกรมใน Leopard

ตอนนี้เริ่มเขียนโปรแกรม หรือว่าลงโน่นลงนี่ใน Leopard แล้ว ตามที่ตั้งใจไว้ แล้วจะเขียนลงใน

ThaiMacDev.com

เรื่อยๆ นะครับ ตอนนี้ก็เพิ่งจะมีเรื่องประสบการณ์การแก้ปัญหา libGL.dylib แต่ว่าถ้ามีเรื่องใหม่ๆ (โดยเฉพาะการเล่นกับ API ด้วยตัวเอง และการรีวิว Xcode กับ Interface Builder ใหม่) ก็จะเขียนลงในนั้นเช่นกัน

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

ช่วงนี้ตรวจข้อสอบเด็กเยอะแยะ ตาลาย ไม่พอ ยังไม่วายเข้าไปดูตาม 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 มากเลย

Web Services: REST vs. SOAP

อ้างอิง: Blognone: REST vs. SOAP Web Services โดย krunapon

ผมอ่านข่าวนี้ที่ blognone ด้วยความรู้สึกอยากจะตะโกนในใจว่า Take the Red Pill! Welcome to the Real World! ยังไงก็ไม่รู้

ใช่ครับ ถึงมันจะไม่ใช่ข่าวที่มีการประกาศใหญ่โตมโหฬาร (แบบ MS, Sun, IBM หรือว่าบริษัทชื่อใหญ่ๆ โตๆ ออกมาให้การสนับสนุนหรือว่าจับมือกันให้ความร่วมมือในเรื่องอะไรสักอย่าง) ที่อาจจะ catch ความสนใจและ convince คนที่อยู่ใน mainstream ได้ง่ายกว่า แต่ว่าก็ดีเหมือนกันที่คนเริ่มลืมตามองความเป็นจริงอันโหดร้ายของ SOAP-based Web Services มากขึ้น

ในหลักการแล้ว SOAP มันก็เป็น protocol ที่ดีนะ แต่ว่าในความเป็นจริงแล้ว เนื่องจากความต้องการของการใช้ Web Services ในปัจจุบัน มันเป็นการเข้าถึง resource แบบ CRUD เสียเป็นส่วนมาก การใช้งาน SOAP-based ในความรู้สึกของผม มันเลยกลายเป็นการขี่ช้างจับตั๊กแตนไปโดยใช่เหตุ และจะต้องมีองค์ประกอบอะไรต่างๆ มากมาย อีกทั้งปัญหาอย่างหนึ่งที่ตามมาในโลกความเป็นจริง ก็คือ ความหลากหลายของข้อมูล ความร้อยพ่อพันแม่ของ representation ทำให้การกำหนดมาตรฐานของ SOAP นั้น นับวันมันจะมีแต่ใหญ่ขึ้น และ bloated ขึ้นอย่างใช่เหตุ …. วิธีการ scale ของ SOAP มันสร้างความยุ่งยากและลำบากเอาเรื่อง

ก็เลยทำให้ตัว S ใน SOAP ซึ่งควรจะย่อมาจาก Simple กลายเป็นเรื่องตลก เพราะว่ามันเป็นทุกอย่าง ทุกอย่างจริงๆ นอกเหนือจาก Simple มันมีทุกอย่าง นอกจาก Simplicity

ที่เขียนนี่ ไม่ได้แปลว่า SOAP ไม่ดี หรือว่า REST คือคำตอบสำหรับทุกอย่างนะ ใครที่รู้จักผมจะรู้ดีว่า สำหรับกรณีแบบนี้ ผมแทบไม่เคย claim คำว่า 100% เพราะว่า exception มันมีแทบทุกเรื่องน่ะแหละ ยากที่จะหาอะไรบางอย่างที่มันเป็นจริงในทุกกรณี .. แต่ว่า exception มันจะต้อง catch และ handling แยกต่างหาก ไม่ใช่ยกมาพูดเป็น counter example หักล้างกับ general cases อยู่เรื่อยไป จนลืม handling กรณี “ทั่วไป” (general cases) อีก 80% ของกรณีทั้งหมด… เช่นกรณีนี้ คือ (น่าจะกว่า) 80% ของความต้องการการใช้งาน Web Services ในปัจจุบันนั้นคือ request resources แบบ remote ซึ่ง REST มันดีกว่าจม และไปอยู่บน (= ใช้ความสามารถของ) protocol ที่มาตรฐานมาก คือ HTTP อีกตะหาก

ในขณะที่บริษัทใหญ่ๆ ที่ชอบนั่งกำหนด standard ก็ยังคงบ้ากับ SOAP-based standard spec กันต่อไป บริษัทใหญ่ๆ ที่ต้องทำงานให้บริการข้อมูลจริงในโลกความเป็นจริง เช่น Google หรือ Amazon (ที่ Web Services มีผลอย่างมากกับ model ทางธุรกิจของตัวเองด้วย) กลับมีแนวโน้มจะกลับมาใช้ REST เพิ่มขึ้นเรื่อยๆ นี่ยังไม่นับถึงบริษัทเล็กๆ อีกนับร้อยนับพัน ที่ต้องให้บริการข้อมูลจริง เชื่อมโยงจริง ใช้งานจริง เป็นส่วนหนึ่งของระบบนิเวศน์ของข้อมูลขนาดใหญ่จริง .. ที่ใช้งาน WS แบบ REST มากกว่าที่จะเลือก SOAP (คนใช้ SOAP มันก็มีนะ ไม่ใช่ไม่มี)

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

และ SOAP vs. REST ก็เป็นอีกบทพิสูจน์หนึ่ง …. ที่ยังคงดำเนินต่อไป

ปล. จริงๆ ผมเคยเขียน blog เรื่อง SOAP หรือว่าทำนองบ่นๆ เรื่อง SOAP ไปแล้วหลายครั้ง

เทอมหน้าวิชา WWW Programming ในส่วนของ Web Services จะสอน REST Web Services เป็นหลัก ส่วน SOAP คงจะยกยอดไป “ถ้ามีเวลา” แทน

[update 1]: ลืมไป ว่าเมื่อไม่นานมานี้ Tim Bray จาก Sun Microsystems ได้มาพูดถึง REST ไว้ด้วย และน่าสนใจทีเดียว และเขียนไว้หลายบทความ รวมถึงการให้สัมภาษณ์หลายครั้งด้วย ลองหาอ่านๆ ได้จาก blog ของเค้าครับ

  • tbray.org (link นี้เฉพาะในส่วนของ Web Services Technology เท่านั้นนะครับ) ภายในแต่ละ link ค่อนข้างยาวทีเดียว น่าอ่านครับ
  • InfoQ: Tim Bray on Rails, REST, XML, Java and More อันนี้สัมภาษณ์
  • Tim Bray: Issues in Web Frameworks เป็น PDF ของ slide ที่ Bray ไปพูดเรื่องเกี่ยวกับ Web Frameworks ครับ มีเรื่อง Web Services ด้วย

[update 2]: เพิ่งอ่านที่ James Clark เขียนเรื่อง Bytes not Infosets ที่ remark น่าสนใจหลายเรื่องเหมือนกัน ที่อาจจะไม่เกี่ยวกับ SOAP vs. REST ตรงๆ แต่ว่าโดนหางเลข เนื่องจาก WS-* แบบ SOAP มัน emphasis กับ XML infosets มากเลย …. และ James Clark (คนที่เราน่าจะฟังมากที่สุดคนนึงในเรื่องของ XML) ก็มี remark ว่า

My conclusion is this: one aspect of the WS-* approach that should not be carried over to the REST world is the emphasis on XML infosets.

เห็นด้วยไม่รู้จะเห็นด้วยยังไง

[update 3]: minor clarifications added

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

Syntax highlighting

คิดๆ อยากจะเขียน code snippet (ที่ไม่เกี่ยวกับ mac development) ลงในนี้บ้างเหมือนกัน แต่ว่ามันไม่มี highlighting เจ๋งๆ เลย ไอ้ตัวที่ใช้อยู่นานนมกาเลอย่าง code2html ก็ดันไม่ highlight Haskell อีก จะเขียนเพิ่มเข้าไปเองก็ขี้เกียจ (ทั้งๆ ที่จริงๆ ก็ทำได้อ่ะนะ แต่ว่า code มันเขียนแบบ Perl-ish มากกกกก แถมไม่ factored ไม่แยก module เท่าไหร่) … อืมมม มันต้องมีคนคิดเหมือนเราสิ ว่าแล้วก็เริ่มหา

สักพักก็ไปเจอหน้า Plugins/Syntax Highlighting ที่ WordPress เอง แต่ว่าเท่าที่อ่านๆ ดูไม่ค่อยจะมีตัวไหนเข้าท่าเลยแฮะ (มันไม่ highlight Haskell ซักกะตัว เท่าที่อ่านแบบผ่านๆ) นอกจาก Vim Color แต่ว่าไอ้ตัวนี้ก็ดันไป dependent กับ Text::VimColor ที่เป็น Perl module ต้องลงผ่าน CPAN อีก เออ ไม่เป็นไร ลงก็ได้ แต่ว่าก็ดัน build ไม่ผ่านซะงั้น (test ผ่านน้อยไปหน่อย) จะ force install ลงเลย ก็ดันไม่ work อีก เฮ้อ เบื่อจริง ก็เลยต้องหาต่อไป

และแล้วเราก็ไปเจอ GeSHi: Generic Syntax Highlighter ที่เขียนในภาษา PHP เราก็เลยเอามาเขียนทำเป็น command line application ง่ายๆ ที่อ่านไฟล์ตาม argument แล้วก็เดาภาษาจาก extension ของไฟล์ แล้วก็พ่น highlighted code ที่เป็น HTML ออกมาให้เรา code-paste ใส่ blog ได้ผลดังนี้ (Haskell)

import List
 
permute [] = [[]]
permute xs = [x:ys | x <- xs, ys <- permute (delete x xs)]
 

หรือว่าภาษา Ruby แบบนี้

class Array  
  def permute
    return [self] if size < 2
    perm = []
    each {|e| (self - [e]).permute.each {|p| perm << ([e] + p)}}
    perm
  end
end
 
[0,1,2,3].permute.each {|e| p e }

ก็ใช้ได้อ่ะนะ แต่ว่ามันอาจจะรก HTML code ไปหน่อยนึง

[update 1]: พอมี line number แล้วมันเละใน blog แฮะ เลยเอาออก ไว้จะแก้ CSS ทีหลัง ตอนนี้ขี้เกียจ (อีกล่ะ)

[update 2]: เพิ่งจะสังเกตจากหน้า web ว่า \\ ใน code haskell มันหายแฮะ เหลือแค่ตัวเดียว .. ไม่รู้เหมือนกันว่าทำไม code ฝั่งนี้ก็ยังอยู่นะ เลยไม่รู้จะว่าไงดี :-(

[update 3]: สุดท้ายก็เลยลงเอยด้วยการเขียน code ใหม่ไม่ให้มันมี \\ อืมมม อ่านเป็นภาษาคนกว่าเก่าแฮะ แต่ว่ามัน geek-ish น้อยลง :-P

[update 4]: อ๊ากกก GeSHi มันไม่มี Erlang highlighting! ว้า กำลังจะหัดเล่นอยู่เลย ว่าแต่ Erlang นี่ทำไมมันลูกเมียน้อยตอนนี้จังเลย emacs ก็ไม่มี (ผมใช้ Carbon Emacs distribution) TextMate ก็ไม่มี มีแต่ vim … สุดท้ายก็ตายรังสินะ แต่ว่า Emacs mode ของ Erlang ก็ไม่น่าหายากเท่าไหร่ [note — ณ ปัจจุบัน เจอแล้ว] ไม่เป็นไร มีเวลาและชินๆ กับ Erlang มากกว่านี้เมื่อไหร่ (พอจะชินกับ module/keywords) แล้วเดี๋ยวค่อยทำเพิ่มเข้าไปใน GeSHi เองก็ได้วะ