เครื่องมือ command-line ใหม่ที่ชื่อว่า run ได้เกิดขึ้นจากชุมชนนักพัฒนา โดยสัญญาว่าจะรวมประสบการณ์การทำงานกับภาษาโปรแกรมมากกว่า 25 ภาษาผ่านอินเทอร์เฟซเดียว สร้างด้วย Rust โดยนักพัฒนา Esubaalew เครื่องมือนี้มีเป้าหมายเพื่อขจัดความจำเป็นในการใช้ REPL แยกต่างหากและให้การรันโค้ดที่สม่ำเสมอในภาษาโปรแกรมต่างๆ
โปรเจกต์นี้ได้สร้างการอภิปรายอย่างมากในหมู่นักพัฒนา โดยเฉพาะเรื่องข้อเสนอหลักและการนำไปใช้ทางเทคนิค Run ช่วยให้นักพัฒนาสามารถรันโค้ด compile โปรแกรม และเข้าถึง REPL แบบ interactive สำหรับภาษาต่างๆ ตั้งแต่ Python และ JavaScript ไปจนถึง Rust และ Go ทั้งหมดผ่าน command-line interface เดียว
ภาษาที่รองรับจำแนกตามหมวดหมู่
| หมวดหมู่ | ภาษาและชื่อย่อ | ความต้องการของ Toolchain |
|---|---|---|
| Scripting และ shells | Bash, Python (py, python), Ruby (rb, ruby), PHP, Perl, Lua, R, Elixir (ex, elixir) | ต้องมี interpreter ที่ตรงกันใน PATH |
| Web และ typed scripting | JavaScript (js, node), TypeScript (ts, deno), Dart, Swift, Kotlin (kt, kotlin) | node, deno, dart, swift, kotlinc + JRE |
| Systems และ compiled | C, C++ (cpp, cxx), Rust (rs, rust), Go, Zig, Nim, Haskell (hs, haskell), Crystal (cr, crystal), C (cs, csharp), Java, Julia (jl, julia) | compiler/toolchain ที่เกี่ยวข้อง |
ชุมชนตั้งคำถามถึงความจำเป็นของ Abstraction Layer อีกชั้นหนึ่ง
ชุมชนนักพัฒนาได้ตั้งคำถามสำคัญว่าเครื่องมือนี้แก้ปัญหาจริงหรือเพียงแค่เพิ่มความซับซ้อนอีกชั้นหนึ่ง นักพัฒนาบางคนชี้ให้เห็นว่าโซลูชันที่มีอยู่แล้วอย่าง shebang lines และ /usr/bin/env ให้ความสามารถในการตรวจจับภาษาและการรันโค้ดที่ทำงานได้อย่างเชื่อถือได้มาหลายสิบปีแล้ว
การอภิปรายนี้เผยให้เห็นความตึงเครียดพื้นฐานระหว่างนวัตกรรมและแนวปฏิบัติที่ยึดถือมาแต่เดิม ในขณะที่บางคนเห็นคุณค่าในการมีอินเทอร์เฟซเดียวสำหรับหลายภาษา คนอื่นๆ ตั้งคำถามว่าการประหยัดเวลาคุ้มค่ากับการเรียนรู้เครื่องมือใหม่อีกตัวหนึ่งหรือไม่ เมื่อโซลูชันที่มีอยู่ทำงานได้อย่างมีประสิทธิภาพ
ความขัดแย้งเรื่องการจำแนกภาษาเกิดขึ้น
ส่วนสำคัญของการอภิปรายในชุมชนได้มุ่งเน้นไปที่วิธีการจัดหมวดหมู่ภาษาโปรแกรมต่างๆ ของเครื่องมือนี้ Swift เป็นตัวอย่างหนึ่งที่ถูกจัดอยู่ในหมวด Web & typed scripting แม้ว่าจะเป็นภาษา compiled ที่ใช้ LLVM เป็น backend คล้ายกับ Rust และ C++ การจำแนกผิดนี้ได้จุดประกายการสนทนาที่กว้างขึ้นเกี่ยวกับวิธีที่เรานิยามและจัดหมวดหมู่ภาษาโปรแกรม
การถกเถียงขยายไปเกินกว่าข้อผิดพลาดในการจัดหมวดหมู่ไปสู่คำถามพื้นฐานเกี่ยวกับคุณสมบัติของภาษา Kotlin เป็นอีกกรณีหนึ่งที่น่าสนใจ เนื่องจากสามารถ compile เป็น native code สำหรับการพัฒนา Android และ JavaScript สำหรับเว็บแอปพลิเคชัน ทำให้การจำแนกหมวดหมู่ขึ้นอยู่กับบริบท
ข้อกังวลเรื่องการนำไปใช้ทางเทคนิคและความสามารถในการขยาย
จากมุมมองทางเทคนิค เครื่องมือนี้ทำงานโดยการเรียกใช้ toolchain ของภาษาที่มีอยู่แล้วแทนที่จะสร้าง interpreter ของตัวเอง engine ของแต่ละภาษาจะ implement trait เล็กๆ ที่จัดการการตรวจจับ toolchain การเตรียม workspace การรันโค้ด และการจัดการสถานะ REPL วิธีการนี้ทำให้ core มีน้ำหนักเบาในขณะที่ยังคงความเข้ากันได้กับสภาพแวดล้อมการพัฒนาที่มีอยู่
นักพัฒนาได้แสดงความสนใจในความสามารถในการขยายของระบบ โดยการอภิปรายเผยให้เห็นว่าการเพิ่มภาษาใหม่ต้องการการ implement LanguageEngine trait และเพิ่มภาษาลงในการกำหนดค่าหลัก กระบวนการที่ค่อนข้างตรงไปตรงมานี้ได้รับการยกย่องว่าเข้าถึงได้ง่าย แม้แต่สำหรับนักพัฒนาที่เพิ่งเริ่มต้นกับ Rust
คำสั่ง REPL ที่ใช้ได้
| คำสั่ง | วัตถุประสงค์ |
|---|---|
:help |
แสดงรายการคำสั่ง meta ที่ใช้ได้ |
:languages |
แสดง engine ที่ตรวจพบและสถานะ |
:lang <id> |
เปลี่ยนภาษาที่ใช้งาน (py, go, ฯลฯ) |
:detect on/off/toggle |
ควบคุมการตรวจจับภาษาของโค้ดอัตโนมัติ |
:load path/to/file |
รันไฟล์ใน session ปัจจุบัน |
:reset |
ล้างสถานะ session ที่สะสมไว้ |
:exit / :quit |
ออกจาก REPL |
วิสัยทัศน์อนาคตและการรวม Cross-Language
บางทีแง่มุมที่น่าสนใจที่สุดของโปรเจกต์นี้คือศักยภาพในการแบ่งปันตัวแปรและการรวมระหว่างภาษาต่างๆ นักพัฒนาได้ระบุแผนที่จะเปิดใช้งานการแบ่งปันตัวแปรระหว่างภาษาต่างๆ ภายใน session เดียวกัน ซึ่งอาจเปิดโอกาสที่น่าสนใจสำหรับ workflow การเขียนโปรแกรมแบบ polyglot
ฟีเจอร์นี้หากสามารถ implement ได้สำเร็จ อาจทำให้เครื่องมือนี้แตกต่างจากโซลูชันที่มีอยู่และให้คุณค่าที่แท้จริงสำหรับนักพัฒนาที่ทำงานข้าม ecosystem ของหลายภาษา อย่างไรก็ตาม ความท้าทายทางเทคนิคในการรักษา type safety และความสม่ำเสมอของข้อมูลข้าม runtime environment ต่างๆ ยังคงเป็นอุปสรรคสำคัญ
โปรเจกต์นี้เป็นการทดลองที่น่าสนใจในด้านเครื่องมือสำหรับนักพัฒนา แม้ว่าประโยชน์ใช้สอยสูงสุดจะยังต้องได้รับการพิสูจน์ ว่าจะได้รับการยอมรับในชุมชนนักพัฒนาที่กว้างขึ้นหรือไม่ น่าจะขึ้นอยู่กับว่าสามารถแก้ไขจุดเจ็บปวดของ workflow จริงได้ดีเพียงใด เมื่อเทียบกับการเพิ่มความซับซ้อนที่ไม่จำเป็นให้กับแนวปฏิบัติที่ยึดถือมาแต่เดิม
อ้างอิง: run