แนะนำบน HN: ภาษาภาพแบบใหม่สำหรับสอนเขียนโค้ดให้เด็ก

 (pickcode.io)
4 คะแนน โดย GN⁺ 2023-11-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Pickcode เป็น IDE ออนไลน์สำหรับ ชั้นเรียนวิทยาการคอมพิวเตอร์ ในระดับมัธยมต้นและมัธยมปลาย โดยมุ่งเป็นแพลตฟอร์มที่เรียบง่ายและเสถียร เพื่อลดเวลาที่ครูใช้ในการจัดการชั้นเรียน
  • ฟีเจอร์หลักด้านการจัดการชั้นเรียน ได้แก่ รองรับ Chromebook, การติดตามงานของนักเรียน, การทำงานร่วมกันแบบเรียลไทม์ และการตรวจดูประวัติโค้ด
  • ครูสามารถปรับแต่งและจัดระเบียบ สื่อการสอนและงานที่มอบหมาย ได้ และ Pickcode ระบุชัดเจนว่าไม่มีฟีเจอร์ช่วยเขียนโค้ดด้วย AI
  • มีความคิดเห็นจากครูว่าเครื่องมือนี้ช่วยให้นักเรียนเข้าถึงได้ง่ายขึ้นและทำงานได้อย่างเป็นอิสระมากขึ้นในชั้นเรียน Java, Web Development, Python และ AP Computer Science Principles
  • เมื่อเทียบกับ IDE ระดับมืออาชีพที่ซับซ้อน เครื่องมือนี้เน้นการสร้างชั้นเรียนและการจัดการนักเรียน จึงอาจเป็นตัวเลือกที่ช่วยลดสิ่งรบกวนในสภาพแวดล้อมห้องเรียนได้

IDE ออนไลน์ที่ออกแบบมาสำหรับห้องเรียน

  • Pickcode เป็น IDE ออนไลน์สำหรับ ชั้นเรียน CS ในระดับมัธยมต้นและมัธยมปลาย
  • เน้นการเป็น แพลตฟอร์มที่เรียบง่ายและเสถียร เพื่อช่วยให้ครูประหยัดเวลาในการจัดการชั้นเรียน
  • มีเส้นทางเข้าใช้งานพื้นฐานไปยังหน้าเริ่มต้นใช้งาน เข้าสู่ระบบ และแผนราคา

ฟีเจอร์จัดการชั้นเรียนและเสียงตอบรับจากครู

  • ฟีเจอร์หลักของ Pickcode มุ่งเน้นไปที่การดำเนินชั้นเรียนและการตรวจสอบงานของนักเรียน
    • ทำงานได้บน Chromebook
    • สามารถติดตามงานของนักเรียนได้
    • รองรับการทำงานร่วมกันแบบเรียลไทม์
    • ตรวจดูประวัติโค้ดได้
    • ปรับแต่งสื่อการสอนได้
    • จัดระเบียบงานที่มอบหมายได้
    • ไม่มีฟีเจอร์ ช่วยเขียนโค้ดด้วย AI
  • ครูประเมินว่าอินเทอร์เฟซเรียบง่ายแต่ขยายการใช้งานได้ และนักเรียนหลายช่วงวัยชื่นชอบ
  • มีกรณีการใช้งานในชั้นเรียน Java, Web Development, Python และ AP Computer Science Principles
  • มีเสียงตอบรับว่าเครื่องมือนี้ช่วยให้นักเรียนใช้งานได้ง่ายขึ้น ติดตามงานได้ และเดินหน้าทำงานอย่างเป็นอิสระ
  • ยังมีความเห็นว่าทีมสนับสนุนตอบสนองรวดเร็วและช่วยเหลือดี อีกทั้งข้อเสนอแนะจำนวนมากได้รับการนำไปพัฒนาใช้งานจริง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-23
ความคิดเห็นใน Hacker News

  • สงสัยว่ามีเหตุผลที่ดีพอหรือไม่ที่ต้องบังคับให้ใช้คีย์เวิร์ด var, set, call เสมอไป ใน BASIC ก็ไม่มีแบบนั้น และจากความทรงจำเลือนรางตอนที่หัดเขียนโปรแกรมครั้งแรกสมัยเด็ก สิ่งเหล่านี้น่าจะเป็น ความซับซ้อนที่ไม่จำเป็น
    ยกตัวอย่างเช่น ใน LOGO แค่เขียน forward 10, left 90 ก็พอแล้ว แต่ call paint.forward(10), call paint.left(90) ให้ความรู้สึกเยิ่นเย้อและรกเกินไป

    • ใส่คีย์เวิร์ดไว้เพื่อให้แต่ละบรรทัด อ่านออกเสียงได้ง่าย โดยเฉพาะใน set x = 7 ที่คีย์เวิร์ดช่วยให้ชัดเจนว่านี่คือการเปลี่ยนค่าตัวแปร ไม่ใช่การยืนยันความเท่ากัน
      ในทางเทคนิค ถ้าอยู่ในบริบทของโปรแกรมวาดรูป จะทำให้ forward() เป็นเมธอดระดับบนสุดก็ได้ แต่ตัดสินใจให้มันมีลักษณะ เชิงวัตถุ มากขึ้น เพื่อเตรียมเด็กนักเรียนไว้สำหรับตอนที่ต่อไปจะไปใช้เอนจินเกม 2D และต้องควบคุมสไปรต์หลายตัว
    • ตรงนี้รู้สึกว่าชื่อไม่ค่อยตรงสัญชาตญาณนัก forward กับ left ดูเหมือนทิศทางการเคลื่อนที่ โดยเฉพาะถ้าอยากให้พู่กัน “เคลื่อนที่ไปทางซ้าย” ก็จะยิ่งสับสน
      จริง ๆ แล้ว forward คือการวาด/เคลื่อนที่ และ left คือการหมุนทวนเข็มนาฬิกาที่รับอาร์กิวเมนต์ติดลบได้ด้วย ดังนั้น call paint.draw(10), call paint.rotate(90) หรือ rotate("up") น่าจะเข้าใจง่ายกว่า
    • ฟังแล้วคงบอกอายุได้ แต่ BASIC ตัวแรกที่ฉันเรียนมี คำสั่ง gosub สำหรับเรียกซับรูทีน
      อนึ่ง เพราะได้ยินมาว่า BASIC รุ่นแรก ๆ เป็นแบบนั้น เลยตั้งใจให้หมายเลขลิงก์เริ่มที่ 1 เหมือนกัน :)
      [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
      [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
    • Basic ที่ฉันใช้มี LET X=10
    • ความประทับใจแรกของฉันก็เหมือนกัน ถึงจะดูโค้ดที่ซับซ้อนกว่านี้มากทั้งวัน แต่ถ้าคิดจากมุมเด็กเล็ก ก็น่าจะทำให้เข้าใจผิดกับ เสียงรบกวนที่ไม่จำเป็น พวกนี้ได้ไม่น้อย

  • ตอนนี้กำลังแนะนำ Godot ให้เด็กอายุ 10 ขวบ ตลอด 6 เดือนที่ผ่านมาเขาสร้างเกมด้วย Scratch และชอบ Scratch มาก แต่ก็หงุดหงิดกับข้อจำกัดของมันเหมือนกัน
    ตอนแรกคิดว่าเขาน่าจะชอบมากกว่าถ้าได้ใช้ภาษาสคริปต์จริง ๆ แต่พอเริ่มใช้ GDScript ก็ท้อเร็วมากเพราะต้องพิมพ์เยอะเกินไป มือยังเล็กจึงพิมพ์สัมผัสได้ยาก และการพิมพ์ชื่อตัวแปรกับการเรียกเมธอดก็ใช้เวลานานเกินไป
    อันนี้ดูเหมือนเป็นจุดสมดุลที่ดีมาก เลยว่าจะลองดู

    • ประเด็นเรื่องความเร็วในการพิมพ์เป็นข้อสังเกตที่ดีมาก และแปลกตรงที่ฉันไม่เคยคิดถึงมันเลย
      ฉันกำลังสอน Python แบบเบามาก ๆ ให้เด็กอายุ 3 ขวบ และก็สงสัยอยู่ว่าทำไมความคืบหน้าถึงช้ากว่าความเข้าใจของเขา ตอนนี้ถึงได้รู้ว่าแค่การพิมพ์วงเล็บกับเครื่องหมายคำพูดก็ใช้เวลานานแล้ว
      ฉันชอบโปรเจกต์นี้และตื่นเต้นที่จะได้ลองใช้ กำลังเริ่มเปลี่ยนมาคิดว่าเรื่องการเขียนโปรแกรมสำหรับเด็กนั้น ยิ่งมีมากยิ่งดี น่าจะดีด้วยซ้ำถ้าให้พวกเขาได้สัมผัสพลวัตของการเลือกจากหลายภาษาและหลายรูปแบบการทำงาน
    • สงสัยว่าทำไมไม่ใช้คีย์บอร์ดขนาดสำหรับเด็ก
    • ประสบการณ์ของฉันก็คล้ายกัน ฉันแนะนำ Scratch ให้ลูกชายตอนอายุ 8 ขวบ และอีก 2 ปีต่อมาตอนนี้เขากำลังทำเกมที่ซับซ้อนกว่าที่คิดไว้มาก
      แต่พอเอาภาษาโปรแกรม “จริง ๆ” ให้ดู เขากลับบอกว่าสิ่งเหล่านั้นทำใน Scratch ได้หมด และไม่จำเป็นต้องพิมพ์เยอะขนาดนั้น
      เราลองทำ GameMaker ด้วยกันและได้ผลลัพธ์ที่เจ๋งมาก แต่พอฉันเผลอแป๊บเดียว เขาก็กลับไปทำโปรเจกต์ Scratch ของตัวเองอีก บางทีก็อดคิดไม่ได้ว่า ถ้าเหมือนตัวฉันสมัยก่อนแล้วเริ่มจากโค้ดตั้งแต่แรกจะดีกว่าไหม ;-)
    • ฉันรู้สึกว่าข้อจำกัดของ Scratch คือ เมื่อโปรแกรม ใหญ่เกินไปแล้วจะจัดการความซับซ้อนอย่างไร มันไม่ชัดเจนสำหรับเด็ก
      แต่เพียงแค่ชี้ให้เห็นปัญหาแล้วถามว่าอยากจัดการอย่างไร เด็กก็จะเริ่มคิดกับปัญหานั้น และหาวิธีต่าง ๆ ที่ทำได้ภายใน Scratch เอง เช่น แบ่งโปรแกรมออกเป็นหลายอ็อบเจ็กต์หรือหลายเอเจนต์
      Scratch ทรงพลังกว่าที่ความประทับใจแรกหรือโปรแกรมแรก ๆ ของมันทำให้คิดมาก
    • GDScript เป็นภาษาที่ดีอย่างน่าประหลาดใจ ดีกว่า Python ในหลายด้าน เช่นมี var และ const

  • ขอแสดงความยินดีกับการเปิดตัว Pickcode รายละเอียดต่าง ๆ ทำได้ดีและเห็นชัดว่าใส่ใจมาก
    ฉันคิดว่าอย่างน้อยก็มีสองแนวทางในสายการเขียนโปรแกรมแบบภาพที่พยายามทำให้การเขียนโปรแกรมเข้าถึงคนที่ไม่ใช่นักพัฒนาได้มากขึ้น
    บางความพยายามใช้ส่วนติดต่อแบบภาพเพื่อลด ภาระในการเรียนรู้ไวยากรณ์ แต่ไม่ได้ซ่อนลักษณะเชิงคำสั่งหรือความจำเป็นของการคิดเชิงอัลกอริทึม จริง ๆ แล้วอาจมองได้ว่าเป็น IDE ที่เข้าถึงได้ในอีกระดับหนึ่ง และฉันคิดว่า Pickcode กับ Scratch อยู่ในกลุ่มนี้
    อีกแนวทางหนึ่งคือการสำรวจพาราไดม์การเขียนโปรแกรมแบบอื่นที่อาจเข้ากับอุปมาเชิงภาพได้ดีกว่าในระดับหนึ่ง และยังชวนให้ผู้ใช้คิดต่างจากการเขียนโปรแกรมเชิงคำสั่งด้วย Node-RED เป็นตัวอย่างที่ดีของการสำรวจการเขียนโปรแกรมแบบอิงโฟลว์ ซึ่งเป็นญาติใกล้ชิดกับการเขียนโปรแกรมเชิงฟังก์ชันแบบรีแอกทีฟ ส่วน LabVIEW ก็เป็นญาติใกล้ชิดอีกตัวในสาย dataflow แต่มีองค์ประกอบที่ดูเหมือนเวทมนตร์มากกว่า ซึ่งจริง ๆ แล้วก็คือค่าเริ่มต้นที่ฉลาดพอสมควรกับการตั้งชื่อตัวแปรภายในโดยอัตโนมัติ Apple Automator ก็ทำให้นึกถึงเหมือนกัน
    ฉันไม่ได้มองว่าฝั่งไหนดีกว่าหรือแย่กว่าอย่างจำเป็น แต่เวลาเห็นภาษาภาพ การนึกถึงความต่างระหว่าง เชิงคำสั่งกับเชิงรีแอกทีฟ มีประโยชน์ เพราะมันทำให้ประสบการณ์ของผู้ใช้ปลายทางต่างกันมาก

    • ฉันยังจำได้ว่าการสอนเวิร์กช็อปภาษา เชิงฟังก์ชัน อย่าง Elm ให้ผู้เริ่มต้น กลับง่ายกว่าสอนผู้เชี่ยวชาญเสียอีก เพราะหัวของผู้เริ่มต้นยังไม่ถูกปนเปื้อนด้วยวิธีคิดแบบ C เชิงคำสั่ง

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

    • มีความพยายามแบบนี้มาเยอะแล้ว ไม่ใช่ไอเดียประเภท “ไม่เคยมีใครคิดมาก่อน” แต่ใกล้เคียงกับ “มีคนจำนวนมากคิดและลองทำแล้ว แต่ก็ชนปัญหาใหญ่แทบจะทันที” มากกว่า
      เท่าที่ผมเข้าใจ ปัญหาใหญ่ในกรณีนี้คือเรามักอยากกำหนดข้อจำกัดให้ทุกสถานะระหว่างทางของโค้ดต้องถูกต้องเชิงความหมายเสมอ ซึ่งดูน่าดึงดูดบนผิวเผิน แต่ในทางปฏิบัติกลับเป็นข้อจำกัดที่ร้ายแรง แม้แต่คนเก่งก็ยังคิดแบบหลวม ๆ ก่อนแล้วค่อยกลับมาแก้โค้ดทีหลัง แม้แต่ในระดับบรรทัดเดียวก็เป็นแบบนั้น การบังคับให้ถูกต้อง 100% ตลอดเวลาขัดกับวิธีคิดจริงของมนุษย์อย่างมาก
      ผมมองว่าความไม่สอดคล้องนี้เป็นเรื่องพื้นฐาน ไม่รู้เหมือนกันว่ามีมนุษย์สักกี่คนที่คิดแบบนี้ แม้แต่นักคณิตศาสตร์มืออาชีพก็ว่ากันว่ามักคิดนำไปก่อน แล้วค่อยเติมความเคร่งครัดทีหลัง ถ้าพวกเขายังไม่ได้เดินหน้าอย่างเคร่งครัดทีละขั้น แล้วใครจะทำได้ล่ะ
      ทุกวันนี้การเขียนโปรแกรมลงตัวอยู่กับ autocompletion ที่เข้าใจความหมาย และคำแนะนำต่าง ๆ และมันอาจไม่ใช่ผลของความขี้เกียจเฉย ๆ แต่อาจเป็นจุดเหมาะสมที่สุดจริง ๆ
      ถ้ามีใครผลักดันเรื่องนี้จนสุด ปัญหาอาจถูกแก้ได้ แต่ถึงจะมีผลไม้ให้เก็บอยู่ตรงนี้ ก็ไม่ใช่ผลไม้ที่ห้อยต่ำแน่นอน
      อย่างที่ saurik บอก โลก Lisp ที่ใช้ Emacs น่าจะใกล้เคียงกับสิ่งนี้ที่สุด แต่ถึงอย่างนั้นก็ยังทำอะไรก็ได้ตามต้องการอยู่ดี เพียงแค่มีเครื่องมือมากมายที่ช่วยให้ทำงานเชิงความหมายมากขึ้น ไม่ได้บังคับอย่างเด็ดขาด
    • รู้สึกว่าก็มีของแบบนี้อยู่พอสมควรไม่ใช่เหรอ เช่น Scratch หรือญาติของมันอย่าง Snap(https://snap.berkeley.edu/snap/snap.html), visual flow editor สำหรับ React(https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...) และของคล้ายกันอย่าง https://retejs.org/
    • มีคนบอกว่าอยากได้ของแบบนี้สำหรับโปรแกรมเมอร์ผู้ใหญ่ แต่จริง ๆ แล้ว Blythe Omnis 7 มีมาตั้งแต่ปี 1996 หรือก่อนหน้านั้นแล้ว เป็นแพลตฟอร์ม/โซลูชัน RAD ที่รองรับทั้ง Windows และ Macintosh
      ตอนนั้นผมได้งานเพราะเป็นผู้สมัครเพียงคนเดียวที่เคยได้ยินชื่อซอฟต์แวร์นี้ แค่เพราะเคยอ่านบทความสั้น ๆ ในแมกกาซีน
      https://en.wikipedia.org/wiki/Omnis_Studio
      วิธีเขียนโปรแกรมด้วยการคลิกรายการดรอปดาวน์และป๊อปอัปนั้นไม่ได้ออกแบบมาดีนัก โปรแกรมจะดูเหมือนรายการ และพอจะแก้ไขหนึ่งบรรทัดก็จะมีโมดัลไดอะล็อกเด้งขึ้นมาให้แก้ได้แค่บรรทัดนั้น แน่นอนว่าไม่มี IntelliSense หรือ code completion
      แค่คิดก็เหมือน PTSD จะกำเริบจนรู้สึกว่าต้องหาเหล้าหรือบุหรี่มาช่วยแล้ว
    • ตัวอย่างเช่น https://github.com/nocode-js/sequential-workflow-designer ก็ออกแบบมาในแนวนี้ คือโปรแกรมตรรกะด้วยการวางการทำงานที่นิยามไว้ล่วงหน้าให้ถูกลำดับ และเป็นการเขียนโปรแกรมใน ระดับสูง
    • เท่าที่รู้ คนที่ใช้ Lisp กับ Emacs จะได้ประสบการณ์แบบนี้ เพราะพวกเขาสามารถคิดและทำงานกับ form ได้ ไม่ใช่แค่ข้อความธรรมดา

  • หนึ่งในฟีเจอร์ที่ผมชอบที่สุดของ Scratch คือ คุณสร้าง syntax error ไม่ได้ บล็อกจะประกบกันได้หรือไม่ได้อย่างใดอย่างหนึ่งเท่านั้น เลยคิดว่าเด็ก ๆ สามารถเริ่มต้นและลองเล่นได้ง่ายขึ้นโดยไม่ต้องมีคำอธิบายหรือการสอนพิเศษแยกต่างหาก
    ผมลองกดโน่นนี่เองหลังจากทำตามไม่กี่ขั้นแรกของ tutorial รูปสี่เหลี่ยม แล้วได้ call math paint.forward() ออกมา ซึ่งเกิด syntax error แน่นอนว่าบรรทัดนั้นไร้สาระ แต่ผมก็หาวิธีว่าคำสั่ง math ควรทำงานอย่างไรไม่เจอ ถ้าตาม tutorial ต่อไปก็คงมีคำอธิบาย แต่ผมคิดว่า การค้นพบได้เอง ก็สำคัญเหมือนกัน

    • Scratch ไม่ทำให้เกิด syntax error ก็จริง แต่ถ้ามีอะไรหลุดจากตำแหน่ง มันก็ไม่บ่นนะ เช่น ถ้าระหว่างจัดการบล็อกแล้วมีอันหนึ่งหลุดออกมา โปรแกรมก็ยังรันได้แต่จะทำงานไม่ถูกต้อง
      พอบล็อกเยอะขึ้น มันอาจซ้อนทับกันจนหาหลักฐานได้ค่อนข้างยาก ยังมีปัญหาเรื่องลืมใส่อาร์กิวเมนต์ของบล็อกด้วย ถึงอย่างนั้นมันก็ยังรันได้แต่ไม่ทำงาน
      visual programming ชัดเจนว่าดีกว่าสำหรับเด็ก ๆ แต่ผมคิดว่าจำเป็นต้องมีแนวทางที่เข้มงวดกว่า Scratch และมี ความสามารถด้านการดีบัก ที่ดีกว่า
    • Scratch หรือจะให้แม่นกว่านั้นคือบล็อก ยังมีข้อดีอีกอย่างคือปรับให้เข้ากับภาษาใหม่ ๆ ได้ค่อนข้างง่าย เราใช้บล็อกให้ลูกค้า IoT ตั้งค่าให้อุปกรณ์ตอบสนองต่ออีเวนต์และส่งอีเวนต์ไปยังอุปกรณ์อื่น และทั้งหมดนี้ถูกแปลงเป็น JSON configuration ที่อัปโหลดขึ้นไป

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

    • รู้สึกว่า UI ตัวแก้ไขแบบบล็อกพวกนี้น่าจะสร้างอัตโนมัติได้จาก คำอธิบายเชิงนามธรรมของไวยากรณ์ แบบที่ใช้ใน parser ของ tree-sitter
      บางครั้งการแก้ไขแบบบล็อกลักษณะนี้ก็ผสานกับการตรวจสอบ type เพื่อให้เติม “ช่องโหว่” ได้อย่างชาญฉลาดผ่านการ query เป็นหลัก ซึ่งน่าจะเห็นได้เด่นที่สุดในตัวแก้ไขสำหรับภาษาฟังก์ชันบริสุทธิ์อย่าง Agda

  • ทำให้นึกถึง BASIC ของ ZX81 ขึ้นมาได้ ตอนนั้นไม่ต้องพิมพ์คีย์เวิร์ด เพราะบนคีย์บอร์ดพิเศษจะมีปุ่มสำหรับแต่ละคีย์เวิร์ดโดยเฉพาะ
    ตัวแก้ไขเป็นแบบรับรู้บริบท หรือพูดอีกอย่างคือ ตัววิเคราะห์โทเคนที่ขับเคลื่อนโดย parser ก็คือตัวผู้ใช้เองนั่นแหละ ตอนนั้นมันให้ความรู้สึกเหมือนเวทมนตร์นิด ๆ ที่เครื่องรู้ได้ว่าเรากำลังจะใส่คำ/ตัวเลขหรือคีย์เวิร์ด และเป็นคีย์เวิร์ดประเภทไหน แม้ในเชิงการศึกษาสิ่งสำคัญจริง ๆ คือฉันเข้าใจเรื่องนี้ก็ตาม
    สิ่งสำคัญของ ZX81 คือมัน เก็บ token แทนข้อความเพื่อประหยัดหน่วยความจำ RAM มีแค่ 1KB และยังต้องรวมหน่วยความจำจอแสดงผลอยู่ในนั้นด้วย ไม่มี GPU แยกต่างหาก การ parse ตั้งแต่ตอนป้อนข้อมูลน่าจะทำให้รันได้เร็วขึ้นด้วย

  • เว็บทำออกมาได้ประณีตมาก แต่ฉันไม่เห็นด้วยกับเป้าหมายทั้งหมด เป็น IDE ที่น่าประทับใจทีเดียว แต่รู้สึกว่าน่าจะโฟกัสที่ subset ของ Python มากกว่าการสร้างภาษาใหม่
    ไม่อย่างนั้นอาจถูกเมินได้ เพราะ Scratch สอนง่ายกว่า ส่วน Python ก็มีประโยชน์กว่าในการเรียนรู้ แบบแรกใช้กับโรงเรียนที่มีครูซึ่งเป็นนักพัฒนา ส่วนแบบหลังใช้กับพ่อแม่โปรแกรมเมอร์ที่สอนลูก
    ฉันเป็นนักพัฒนาซอฟต์แวร์และเคยช่วยภรรยาสอนวิชาการเขียนโปรแกรมในระดับประถม/อนุบาล เลยพอรู้ปัญหาในพื้นที่นี้อยู่บ้าง

    • สงสัยว่ามีทางเลือกที่เข้าข่าย “subset ของ Python” ไหม ถ้ามีสะพานเชื่อมที่เป็นธรรมชาติไปสู่การเขียนโปรแกรม “จริง” ก็น่าจะน่าสนใจ

  • บทความที่เกี่ยวข้อง:
    Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - พฤศจิกายน 2022, 14 คอมเมนต์
    Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - กรกฎาคม 2022, 32 คอมเมนต์
    Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - พฤษภาคม 2022, 4 คอมเมนต์
    การโพสต์ซ้ำหลังจากผ่านไปประมาณ 1 ปีก็ถือว่าโอเค และลิงก์ไปเธรดก่อนหน้าก็มีไว้สำหรับผู้อ่านที่อยากรู้เพิ่ม

  • กำลังทำแนวคิดคล้ายกันในฝั่ง music programming อยู่:
    https://glicol.org
    คิดว่าน่าจะดีถ้ามีตัวอย่างสักสองสามอย่างอยู่บนหน้า landing page เลย
    พอลองทำบทเรียนก็ไปต่อไม่ถูก แม้จะมีคำใบ้อยู่ด้านขวาแต่ก็ไม่ได้เด่นมากนัก น่าจะลองจัดใหม่แบบ Svelte Tutorial(https://learn.svelte.dev/tutorial/welcome-to-svelte) ได้
    ยังไม่ค่อยมั่นใจกับไวยากรณ์นัก สงสัยว่าเคยคิดจะใช้ LOGO ไหม