สรุปงาน Code Chill Chill #5 สไตล์คนฟัง !

สวัสดีครับ กลับมาอีกแล้วกับ โค๊ตชิว ๆ ครั้งนี้ก็เป็นครั้งที่ 5 กันแล้ว หลังจากสมรภูมิแห่งการจองบัตรกันมา และแล้ววันที่รอคอยก็มาถึง มางานกันได้แล้ว! เริ่มด้วยบรรยากาศการลงทะเบียนกันก่อนเลย คนเยอะมาก ๆ เลย แน่นนิดหน่อย แต่ก็สนุกดีนะครับ

สถานที่จัดงานของเราก็เป็นที่ Launchpad เป็น Co-Working Space (เกือบ) ติด BTS ที่ดูดีมากเลยทีเดียว น่าสิงอยู่มาก ๆ

เกือบ ๆ ทุ่มนึงแล้ว เราก็เริ่มงานกันได้เลย พบกับพี่แม๊กซ์ของเรา กับการแนะนำกิจกรรมที่กำลังจะจัดในอนาคตอันใกล้นี้!

และพี่ปิงของเราก็ได้มาพูด ในเรื่องของจุดประสงค์ในการจัดงาน และจุดประสงค์ของสมาคมของเราอีกด้วย

เริ่มต้นกับหัวข้อแรกด้วย “How scala differs from others?”

และแล้วก็เป็นเวลาอันสมควร ที่เราจะได้เข้าเรื่องหลักของวันนี้สักที กับเรื่องแรก เป็น Speech จากคุณธนินธ์ ในหัวข้อ “How scala differs from others” มาดูกันว่าจะพูดถึงเรื่องอะไรบ้างหลักๆ แล้วจะเป็นการแนะนำภาษา Scala ว่ามันเป็น Functional Programming แบบชนิดที่ว่าเต็มตัว จริงจังและสวยมาก แต่ข้างในแล้วก็ยังเป็น Imperative เป็นสุดโต่งเช่นกัน โดยหลักการของมันก็คือ การดันส่วนที่เป็น Imperative ลงไปไว้ข้างล่างให้หมด และให้ด้านบนเหลือแต่ส่วนที่เป็น Functional ล้วน ๆ เลย และยังเสริมว่า การเขียน Functional Programming ก็ทำให้โค๊ตของเราสวยได้อีกด้วยนะ จากการยกตัวอย่าง

def getUserId()(implicit request: RequestHeader) = {
  request.cookies.get("uid").map(_.value.toLong).filter(_ > 0)
}

เมื่อเราเอามันมาเปรียบเทียบกับภาษาที่เป็น Imperative

func getUserId(r *http.Request) (int64, error) {
  c, err := r.Cookie("uid")
  if err != nil {
    return 0, err
  }
  i, err := strconv.ParseInt(c.Value, 10, 64)
  if err != nil {
    return 0, err
  }
  if i <= 0 {
    return 0, fmt.Errorf("invalid user id")
  }
  return i, nil
}

จะเห็นได้ว่า มันยาว กว่ากันเยอะเลย แล้วเวลาอ่าน ก็อ่านค่อนข้างจะยากกว่าสักหน่อยเหมือนกันนะ (แต่ในใจจริงๆ ชอบ Imperative มากกว่า อาจจะเพราะว่า ไม่ค่อยมีประสบการณ์กับ Functional ก็ได้นะ)

มีบวกก็ต้องมีลบ เจ้า Scala เองมันก็มีข้อเสียอยู่ในตัวเหมือนกัน ข้อเสียของมันก็เกิดจากข้อดีของมันเหมือนกัน นั่นคือ มันสามารถ Implement Code เราได้หลายวิธีมากเกินไป จนน่ากลัวมากๆ และมันทำให้เราจะต้องมา Refatoring Code ของเราค่อนข้างที่จะเยอะ และต้องละเอียดมาก ๆ

อีกข้อเสียของ Scala นั่นคือมัน ซับซ้อนมาก !  เนื่องจากอย่างที่บอกไปว่า Scala มันดัน Imperative ลงไปด้านล่าง และข้างบนก็เรียกอย่างเดียวทำให้มันต้องมี libraries ทีค่อนข้างซับซ้อนยากต่อการเรียนรู้มากๆ

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

และสุดท้ายของหัวข้อ นี้ขอจบด้วยประโยคที่ว่า

“Scala is everything!”

มาถึงหัวข้อที่ 2 กันกับเรื่อง Functional Programming Design Pattern

เรื่องนี้พูดโดย อ.สรรเสริญ เป็นอาจารย์มาจาก IC ม.มหิดล นี่เอง แต่วันนี้ไม่ได้มาด้วยสไลด์สไตล์อาจารย์มหาลัยแต่อย่างไร ! เราจะมาดูกันว่าเรามี Design Pattern อะไรที่ใช้กันในเชิง Functional Programming กันบ้าง

โดยสรุปจะเป็นรูปแบบการเขียนพวก Functional Programming ว่ามันต่างกับ Imperative Programming ที่หลาย ๆ คนกำลังใช้อย่างไรบ้าง

• Functional Programming เน้นที่เป้าหมายมากกว่า แต่ในขณะเดียวกัน Imperative เราเน้นที่ ระหว่างทางนั่นคือ Process มากกว่า
• Imperative Programming เราจะเน้นไปที่การอ่านแบบ บรรทัด ต่อ บรรทัด ยาว ๆ กันไปเรื่อย ๆ บรรทัดนึงมักจะส่งผลต่อให้อีกบรรทัดนึงเสมอ
• Functional Programming ชื่อก็ Functional เราก็ต้องใช้ Function ในการทำงานเป็นส่วนใหญ่เลย

นอกจากความแตกต่างแล้ว ยังพูดถึงสไตล์ในการเขียนอีกด้วย มาที่อย่างแรกกันก่อนเลย State & Immutability นั่นคือการที่ เราจะไม่เปลี่ยนค่าตัวแปร ซึ่งใน Imperative เราก็จะเขียนโดยให้มีการเปลี่ยนค่าตัวแปรของเราไปเรื่อย ๆ ถ้าเราต้องการอ่านโค๊ต เราก็ต้องมานั่งไล่อ่าน ไล่ค่าตัวแปร ไปเรื่อย ๆ แต่ในเชิง Functional Programming เราจะไม่ทำเช่นนั้น เราจะสร้างตัวแปรนั้นแล้วเอามาใช้ แทนที่จะเขียนทับของเดิม

ถัดมาคือ เราใช้ Function กับทุก ๆ อย่างจริง ๆ ชื่อมันก็บอกอยู่ว่า Functional Programming เพราะฉะนั้นเราก็ต้องใช้เป็น Function เกือบทั้งหมด ถ้ายัง งง กันอยู่ ให้เรานึกว่า Function มันคือกล่องนึง ที่ข้างในเป็นอะไรก็ได้ตามที่เราต้องการ มันรับข้อมูลเข้าไป และคายข้อมูลออกมาเป็น ข้อมูลที่เราต้องการนั่นเอง

ใน Functional Programming เราจะแยกสิ่งที่เรียกว่า Behaviour กับ Data อย่างชัดเจนมาก ๆ ซึ่งเป็นอะไรที่ผมชอบมาก เพราะมันทำให้ เราออกแบบได้เป็นระเบียบมากขึ้นเยอะมาก

สุดท้ายก็ต้องขอบคุณ ผู้ที่มาร่วมงานทุกท่าน Sponsor ทุกรายครับ ที่ทำให้งานดี ๆ แบบนี้เกิดขึ้นมาครับ ขอบคุณครับ

Link ดู Video งาน