จากตอนเดิม สัมภาษณ์ Guillaume Laforge ผู้ดูแลโครงการ Groovy คำตอบมาแล้ว ขอบคุณคุณ cblue ที่ช่วยประสานงานให้ด้วยครับ

ประวัติ

ทำไมคุณและทีมงานถึงได้สร้าง Groovy ขึ้นมา?
อะไรเป็นแรงบันดาลใจของคุณ?
แพลตฟอร์ม/ภาษาโปรแกรมเดิมที่มีนั้นไม่เพียงพอต่อความต้องการงั้นหรือ?

Groovy เกิดขึ้นเพราะเราอีดอัดกับข้อจำกัดของจาวา หลังจากที่คุณได้ลองเขียน Python, Smalltalk หรือ Ruby แล้ว คุณจะพบว่ามีฟีเจอร์หลายอย่างที่เราอยากให้มีในจาวาด้วย

Groovy นำฟีเจอร์มาจากภาษาเหล่านี้
โดยเราต้องการใส่ความเป็นไดนามิกลงไปในภาษาแบบจาวา

ทำไมถึงควรใช้ Groovy?

Groovy จะช่วยให้การพัฒนาโปรแกรมง่ายขึ้น มีประสิทธิภาพมากขึ้นได้อย่างไร?

ปัญหาอย่างแรกสุดของนักพัฒนาคือ มักจะเสียเวลาไปกับการอ่านโค้ดเก่า
ไม่ว่าจะเป็นของเราเองหรือโค้ดของคนอื่น ซึ่งไวยากรณ์ของ Groovy
ถูกออกแบบมาเพื่อให้อ่านง่าย และเข้าใจได้ตรงกัน (concise)
เพื่อให้การดูแลโค้ดเดิมทำได้ง่ายขึ้นมาก

ส่วน Grails เป็นเฟรมเวิร์คที่กำหนดข้อตกลงหรือ convention มาให้คุณสำเร็จ ไม่ต้องเสียเวลามาสนใจการติดตั้งหรือปรับแต่งให้โค้ดแต่ละส่วนทำงานด้วยกันได้ แล้วเอาเวลาตรงนี้ไปใช้พัฒนาฟีเจอร์แทนจะดีกว่า

นอกจากนี้ วงรอบการพัฒนาของ Grails ยังช่วยให้คุณเห็นการเปลี่ยนแปลงทันที
โดยไม่ต้อง deploy ใหม่ทุกครั้ง ซึ่งเป็นผลมาจากระบบ reload ของ Grails
ที่ค่อนข้างฉลาด

Groovy กับ Grails จะมาแทนการเขียนจาวาแบบเดิมหรือเปล่า?

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

สำหรับคนที่เขียนจาวาหรือภาษาอื่นๆ เป็นอยู่แล้ว จะหัด Groovy/Grails
ได้ยากง่ายเพียงไร

ถ้าเขียนจาวาเป็นอยู่แล้ว จะหัด Groovy/Grails ได้ง่ายพอสมควร
เพราะไวยากรณ์ของ Groovy นั้นนำมาจาก Java 5 ซะเยอะ
คลาสส่วนใหญ่ในจาวาที่คุณเคยใช้ก็ใช้ได้ใน Groovy เกือบทั้งหมด

ส่วน Grails นั้น รับรองว่านักพัฒนาเว็บจะติดใจใน convention
ของตัวเฟรมเวิร์ค และจะรู้สึกว่าทำไมเราอดทนใช้เฟรมเวิร์คจาวาแบบเดิมๆ
มาตั้งนานนะ ;-)

Groovy/Grails ทำทุกอย่างที่จาวาทำได้หรือเปล่า

ใช่เลย ไม่มีอะไรที่คุณทำใน Groovy/Grails ไม่ได้

เอา Groovy ไปใช้กับ JavaFX ได้หรือเปล่า? ถ้าใช้ได้ มันจะดีแค่ไหน?

ผมคิดว่ามีพรีเซนเตชันเรื่องนี้ในงาน JavaOne 2008 แต่จำรายละเอียดไม่ได้

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

ผมอยากแนะนำให้ลองดูโครงการ Griffon
ซึ่งเป็นการนำ Groovy มาใช้พัฒนา RIA โดยไม่ผ่าน JavaFX

ผมคิดว่าผู้ใช้ Groovy ส่วนใหญ่มาจากคนที่เขียนจาวาอยู่ก่อน มีคนใช้
Groovy ที่โตมาจากภาษาอื่นๆ (เช่น .NET) เยอะแค่ไหน?

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

ความน่าเชื่อถือของ Groovy

อยากให้คุณช่วยยกตัวอย่างการใช้ Groovy ที่ดังๆ

ตัวอย่างของ Groovy นั้นหาดูได้ยากกว่า Grails
เพราะมีโอกาสที่มันจะถูกใช้ในงานอื่นนอกจากเว็บ เท่าที่ผมรู้
กระทรวงยุติธรรมของฝรั่งเศสใช้ Groovy เป็นเครื่องมือพัฒนาแบบ
Model-driven architecture
โดยใช้อ่านโครงสร้างโมเดลจาก UML เพื่อมาสร้างแอพพลิเคชันใน Struts

อีกตัวอย่างคือสถาบันวิจัยโรคมะเร็งของสหรัฐ ใช้ Groovy
ในงานแบบแบตช์เพื่อตรวจเช็คความถูกต้องของข้อมูลผู้ป่วยหลักหมื่น
นอกจากนี้ยังมีบริษัทประกัน Mutual of Omaha ซึ่งติดอันดับ Fortune 500
ใช้ Groovy ในแอพพลิเคชันคำนวณความเสี่ยงของลูกค้าที่ทำประกัน

จริงๆ ยังมีอีกมากซึ่งถ้าให้ผมเล่ายาวๆ ผมก็เล่าได้เรื่อยๆ เลย

นอกจากนำ Groovy ไปใช้สร้างเว็บแอพพลิเคชันแล้ว ยังสามารถเอา Groovy
ไปใช้ในงานอื่นๆ อย่างมือถือหรือ RIA ได้หรือเปล่า?

ผมคิดว่าคุณหมายถึงการเอา Groovy ไปใช้ในงานอื่นที่ไม่ใช่ Grails

Groovy นั้นใช้ความสามารถบางส่วนของ JDK รุ่นใหญ่
ทำให้มันไม่สามารถเอาไปรันบนแพลตฟอร์มมือถืออย่าง Java ME ได้ แต่ว่า
Groovy นั้นถูกนำไปใช้ในงานอื่นๆ มากมาย เช่น นำไปเขีนนปลั๊กอินภายในระบบ
Wiki (http://xwiki.org)

อีกตัวอ่างคือพอร์ทัล eXo Platform
ซึ่งใช้ Groovy เขียนเทมเพลตสำหรับ views ของพอร์ทัล
โครงการนี้มีจำนวนโค้ดภาษา Groovy ระดับล้านบรรทัด

นอกจากนี้ยังมีเครื่องมือสำหรับทดสอบเว็บเซอร์วิสชื่อ SoapUI
ซึ่งสามารถเขียนเงื่อนไขการทดสอบด้วยสคริปต์ Groovy ได้

Groovy ยังสามารถนำไปใช้งานกับ Spring ได้ คุณสามารถใช้งาน Plain Old
Java Object (POJO) กับ Plain Old
Groovy Objects (POGO) เข้าด้วยกันได้ สรุปว่า Groovy มีอยู่ทั่วไปหมดล่ะ

คุณคิดว่าอีกนานแค่ไหน Groovy/Grails
จึงจะได้รับการยอมรับจากองค์กรขนาดใหญ่
ในการพัฒนาแอพพลิเคชันที่สำคัญมากๆ?

จริงๆ มันถูกยอมรับแล้วนะ!

บริษัทขนาดใหญ่หลายแห่งได้ใช้ Groovy/Grails สำหรับงานสำคัญๆ
อย่างพอร์ทัลที่มีคนเข้าจำนวนมาก ตามที่ผมได้ยกตัวอย่างไปแล้ว

สำหรับประเด็นเรื่องการดูแลรักษาโค้ด (maintainability)
และความสามารถในการขยาย (scalability) ให้เทียบ Groovy/Grails
กับภาษาอื่นๆ อย่าง Python หรือ PHP แล้วเป็นอย่างไร?

บริษัท G2One และทีมพัฒนา Groovy ใส่ใจในประเด็นนี้มาก และพยายามพัฒนาให้
Groovy สามารถขยายตัวไปบนเครื่องระดับท็อป
ในขณะเดียวกันก็ยังคงอ่านเข้าใจได้ง่าย
และรักษาความง่ายในการดูแลรักษาโค้ดเอาไว้
เมื่อรวมกับเราอิงแพลตฟอร์มที่พัฒนามานานแล้วอย่างจาวา ผมคิดว่า Groovy
แข่งขันกับแพลตฟอร์มหรือภาษาอื่นๆ ได้แล้วล่ะ

แล้วถ้าเป็นงานง่ายๆ ทำเร็วๆ (quick & dirty) ล่ะ Groovy
สามารถใช้แทนการเขียนจาวาแบบเดิมได้แค่ไหน มีปัญหาอะไรหรือเปล่า?

ไม่ว่าจะเป็นงานใหญ่หรืองานเล็ก Groovy และ Grails ทำได้หมดนั่นล่ะ

แล้วถ้าเป็นงานระดับสำคัญๆ ในองค์กรล่ะ ใช้ Groovy แทนจาวาได้แค่ไหน?

เหมือนที่ผมตอบไปแล้วว่า ประเด็นไม่ได้อยู่ที่การเข้ามาแทนจาวา
หรือกลายเป็นจาวาภาคใหม่ ถึงแม้ว่าคุณจะสามารถสร้างแอพพลิเคชันด้วย
Groovy หรือ Grails โดยไม่ต้องเขียนโค้ดจาวาเลย คุณก็ควรจะมองว่า Groovy
กับ Grails เป็นส่วนเติมเต็มให้กับแพลตฟอร์มจาวา
เป็นเครื่องมือชิ้นใหม่ของคุณมากกว่า

คุณสามารถผสมผสานแพลตฟอร์มจาวาเดิม (ตัวภาษา, JDK, API ของ third-party)
กับ Groovy และ Grails ได้อย่างมีประสิทธิภาพ

ประเด็นด้านเทคนิคของ Groovy

จากแนวคิด Convention Over Configuration ของ Spring และ Groovy
คุณแก้ปัญหาเรื่องไฟล์คอนฟิกและการส่งพารามีเตอร์จำนวนมากอย่างไร?

Grails เป็นตัวอย่างที่ดีมากในการกำจัดไฟล์คอนฟิกเหล่านี้
คุณจะจำเป็นต้องใช้ไฟล์เหล่านี้ก็ในกรณีที่ต้องการปรับแต่งแอพพลิเคชันที่สร้างด้วย
Grails อย่างละเอียดเท่านั้น

ข้อดีของการใช้ภาษาไดนามิกอย่าง Groovy และเฟรมเวิร์คที่เป็น agile อย่าง
Grails คือคุณสามารถหาวิธีใหม่ๆ ในการปฏิบัติตาม convention ได้
มันเลยส่งผลให้การตั้งค่าปรับแต่งแอพพลิเคชันนั้นง่ายขึ้นมาก

Java Specification Request (JSR)

นอกเหนือจากการที่ Groovy มาเป็นมาตรฐาน
JSR แล้ว
คุณคิดว่ายังมี JSR ตัวอื่นๆ ที่จะส่งผลกับอนาคตของ Groovy
อะไรอีกบ้าง?

อันที่ชัดเจนที่สุด คือ "invokeDynamic" ซึ่งจะเป็นมาตรฐานส่งผลต่อ
Groovy อย่างมาก JVM นั้นเป็นเทคโนโลยีที่ดีมาก
แต่ถึงแม้ว่าเราสามารถสร้างภาษาแบบไดนามิกบน JVM ได้สำเร็จ แนวทางของ JVM
ก็ยังเหมาะสำหรับภาษาแบบสเตติกอย่างจาวามากกว่า

การสร้าง calling dynamic method ไม่ใช่เรื่องง่าย
และเราต้องทุ่มทรัพยากรลงไปจำนวนมากเพื่อสร้างสิ่งนี้ใน JVM

ดังนั้นถ้ามาตรฐานนี้เสร็จ (หวังว่าจะทัน JDK 7) คำสั่งใหม่ๆ
ในไบต์โค้ดที่เกิดขึ้นจากมาตรฐานนี้ จะช่วยให้คนพัฒนาภาษาไดนามิกอย่างเรา
ใช้งาน JVM ได้อย่างมีประสิทธิภาพขึ้นอีกมาก

คุณคิดว่า Groovy จะมีอิทธิพลต่อมาตรฐาน JSR ตัวอื่นๆ หรือไม่?
ตัวอย่างเช่น เอา Groovy ไปจัดการระบบการตั้งค่าของ JSF

เราลงแรงในมาตรฐาน invokeDynamic พอสมควร มาตรฐาน JSR
อันนี้จะมีผลอย่างมากต่อภาษาไดนามิกอย่าง Groovy

ส่วนมาตรฐานตัวอื่นๆ นั้นตอบยาก ภาษาไดนามิกแบบ Groovy
ช่วยเปิดมุมมองใหม่ให้กับปัญหาแบบเดิม
ผมหวังว่ามันจะช่วยสร้างไอเดียให้กับโปรแกรมเมอร์จาวาทั่วโลกเช่นกัน

อนาคตของ Groovy

ผมอยากทราบว่าคุณจะขยายชุมชนของ JSR-241 (ชื่อสเปกของ Groovy)
ให้เติบโตขึ้นอย่างไร ทั้งในแง่ธุรกิจและเทคนิค?

บริษัทนั้นไม่รอให้ Groovy เป็น JSR เพื่อจะใช้ Groovy ในงานระดับสำคัญๆ
หรอก มีบางบริษัทเท่านั้นที่สนใจกระบวนการมาตรฐานของ JSR

การที่ Groovy เป็นมาตรฐาน JSR จะช่วยให้อุ่นใจว่า Groovy ไม่หายไปไหน
และยังพัฒนาต่อไปในอนาคตเสียมากกว่า

วิสัยทัศน์ของคุณต่อ Groovy ในอีก 5 ปีข้างหน้า เป็นอย่างไร?

อีกตั้ง 5 ปีเลยเหรอ?

ทีมของเรายึดกับสภาพความเป็นจริงในปัจจุบัน เท่าที่ผมเห็นมา Groovy
เป็นที่รู้จักมากขึ้นเรื่อยๆ และถูกใช้มากขึ้นเรื่อยๆ เช่นกัน Groovy
จะพัฒนาโดยเน้นการสร้างนวัตกรรมใหม่ให้กับแพลตฟอร์มจาวาต่อไปเรื่อยๆ
ตัวอย่างที่ผ่านมาคือ Groovy สนับสนุน closure และ property
ตั้งแต่มันเริ่มพัฒนาในปี 2003
ซึ่งสมัยนั้นจาวายังไม่มีฟีเจอร์สองอย่างนี้เลย

ดังนั้นเราหวังว่าเราจะทดลองไอเดียและฟีเจอร์ใหม่ๆ
ที่ช่วยให้นักพัฒนาเขียนโปรแกรมได้สนุกขึ้น มีประสิทธิภาพมากขึ้น
และมีอิสระในการทดลองสิ่งใหม่ๆ
รวมถึงเป็นประโยชน์ต่อลูกค้าและผู้ใช้งานมากขึ้น