เหตุผลที่ใช้ Pascal

 (castle-engine.io)
2 คะแนน โดย GN⁺ 2023-07-10 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Object Pascal มีเป้าหมายที่จะรวม ภาษาเชิงวัตถุสมัยใหม่ที่อ่านง่าย เข้ากับ ประสิทธิภาพแบบเนทีฟ และเป็นตัวเลือกสำหรับการสร้างแอปพลิเคชันที่ดูแลรักษาได้บนหลายแพลตฟอร์ม
  • ด้วยระบบชนิดข้อมูลที่เข้มงวด การตรวจสอบขณะคอมไพล์ และการตรวจสอบขณะรันไทม์ จึงช่วยกรองข้อผิดพลาดอย่างการพิมพ์ชื่อผิดหรือชนิดข้อมูลไม่ตรงกันได้ง่าย ก่อนที่จะไปถึงผู้ใช้
  • หากจำเป็นก็สามารถใช้ pointer, โค้ดเฉพาะ OS·CPU, ไปจนถึงแอสเซมบลีได้ แต่ Castle Game Engine เลือกแนวทาง คงโค้ดให้เร็วโดยไม่ใช้แอสเซมบลี
  • สามารถพัฒนาเป้าหมายได้กว้างตั้งแต่ Windows, Linux, macOS, มือถือ, คอนโซล, ไปจนถึงเว็บ และใน Castle Game Engine โค้ดของเอนจินและโค้ดของเกมเขียนด้วยภาษาเดียวกัน
  • มี FPC, Lazarus, Delphi, การรวมเข้ากับ VS Code และการเชื่อมต่อกับไลบรารีหลากหลาย ทำให้สามารถจัดเวิร์กโฟลว์การพัฒนาที่ใช้งานได้จริงภายใน ecosystem ของ Pascal

Object Pascal ที่อ่านง่ายและปลอดภัยด้านชนิดข้อมูล

  • Object Pascal ถูกมองว่าเป็น ภาษาข้ามแพลตฟอร์มที่ปลอดภัยด้านชนิดข้อมูล ซึ่งทันสมัย อ่านง่าย และรวดเร็ว
  • หากรู้จักภาษาเชิงวัตถุอื่นอยู่แล้ว ก็สามารถเรียนรู้ได้ค่อนข้างง่าย และสามารถใช้ Modern Object Pascal Introduction for Programmers เป็นสื่อการเรียนรู้ได้
  • มีความสามารถที่คาดหวังได้จากภาษาเชิงวัตถุสมัยใหม่
    • class
    • unit
    • property
    • generic
    • interface
    • reflection
    • closure
  • ไวยากรณ์เน้นไปที่ โค้ดที่อ่านง่าย
  • เพื่อความปลอดภัยด้านชนิดข้อมูล จึงมีชนิดข้อมูลแยกสำหรับ boolean, string, char, set, enum, range
    • การแปลงที่ปลอดภัย เช่น การกำหนดค่าจำนวนเต็มให้กับ float สามารถทำได้ง่าย
    • นอกเหนือจากนั้นต้องแปลงอย่างชัดเจน

วิธีจับข้อผิดพลาดระหว่างคอมไพล์และรันไทม์

  • Object Pascal ให้ความสำคัญกับ การตรวจสอบขณะคอมไพล์
  • เมื่อต้อง refactor เช่น การจัดโครงสร้างข้อมูลใหม่ สามารถทำให้คอมไพเลอร์แสดงจุดที่ต้องแก้ไขได้
  • ความผิดพลาดที่ชัดเจน เช่น การพิมพ์ชื่อผิดหรือชนิดข้อมูลไม่ตรงกัน จะไม่ผ่านการคอมไพล์และไม่ไปถึงผู้ใช้
  • ยังมีการตรวจสอบขณะรันไทม์เพิ่มเติม
    • การตรวจสอบขอบเขตของอาร์เรย์
    • การตรวจสอบ integer overflow
    • assertion
    • การตรวจสอบ memory leak
  • การตรวจสอบขณะรันไทม์ใช้เพื่อจับปัญหาในเวอร์ชัน debug และสามารถปิดได้ในเวอร์ชัน release ที่เน้นประสิทธิภาพ
  • เมื่อคอมไพล์ด้วย CGE editor จะมีการตั้งค่าโหมด debug / release อัตโนมัติ และสามารถสลับโหมดได้จากเมนู “Run”
  • เอกสารที่เกี่ยวข้องคือ What are range and overflow checks (and errors) in Pascal และ Detecting Memory Leaks

ประสิทธิภาพแบบเนทีฟและการควบคุมระดับล่างเท่าที่ต้องการ

  • Object Pascal คอมไพล์เป็น native code จึงทำให้ได้ประสิทธิภาพการรันพื้นฐานได้ไม่ยาก
  • สำหรับแอปพลิเคชันทั่วไป มักไม่จำเป็นต้องลงไปถึงการปรับแต่งระดับล่างมากนัก
  • หากจำเป็นก็สามารถใช้ความสามารถระดับล่างได้เท่าที่ต้องการ
    • การใช้ pointer
    • การคำนวณกับ pointer
    • การเขียนโค้ดเฉพาะ OS·CPU
    • การเพิ่มโค้ดแอสเซมบลี
  • Castle Game Engine ตั้งเป้าให้รันได้รวดเร็ว โดยไม่มีโค้ดแอสเซมบลีเลย เพื่อเพิ่มความสามารถในการพกพาและความอ่านง่ายของโค้ด
  • การคอมไพล์ก็ถือว่าเร็ว โดยมีตัวอย่างที่เมื่อเปิดโปรเจกต์ใหม่ครั้งแรก การบิลด์เดสก์ท็อปใช้เวลา 2.5 วินาที และการบิลด์ Android ใช้เวลา 10.1 วินาที

หลายแพลตฟอร์มและแนวทางพัฒนาของ Castle Game Engine

  • Object Pascal สามารถใช้พัฒนาเป้าหมายได้หลากหลายแพลตฟอร์ม
    • เดสก์ท็อป: Windows, Linux, macOS, Raspberry Pi, FreeBSD, และอาจรวมถึง Unix ทั้งหมด
    • มือถือ: Android, iOS
    • คอนโซล: Nintendo Switch
    • เว็บ: WebAssembly, JS ผ่าน pas2js
  • แพลตฟอร์มที่ Castle Game Engine รองรับดูได้ที่ Castle Game Engine platforms supported
  • เป้าหมายที่รองรับทั้งหมดดูได้จาก FPC target platforms และ Delphi target platforms
  • ใน Castle Game Engine โค้ดของเอนจินและโค้ดของเกมเขียนด้วยภาษาเดียวกัน
  • เอนจินเป็นโอเพนซอร์ส และสามารถ fork CGE เพื่อปรับแก้ให้เหมาะกับความต้องการได้

ระบบนิเวศของไลบรารีและเครื่องมือพัฒนา

  • Pascal มีไลบรารีและยูนิตเดิมในหลายสาขา
    • ฐานข้อมูล
    • XML, JSON
    • AI
    • บล็อกเชน
    • เครือข่าย
  • สามารถรวมเข้าหรือเชื่อมลิงก์กับไลบรารีเดิมที่มี C API ได้ง่าย
    • ตัวเรนเดอร์
    • ไลบรารีเสียง
    • เอนจินฟิสิกส์
  • ยังสามารถใช้ Python libraries in Pascal ได้
  • ระบบนิเวศของเครื่องมือหลักมีดังนี้
    • FPC: คอมไพเลอร์ Free Pascal แบบโอเพนซอร์ส
    • Lazarus: Pascal IDE แบบโอเพนซอร์สบนพื้นฐานของ FPC
    • Delphi: คอมไพเลอร์ Pascal และ IDE เชิงพาณิชย์
    • VS Code: เครื่องมือหลายตัวของ CGE และ ecosystem ของ Pascal รองรับการรวมเข้ากับ VS Code อย่างชัดเจน

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

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

 
gmong 2023-07-20

Delphi.. ชวนให้นึกถึงความหลังเลยนะครับ Borland, Delmadang..
 
xguru 2023-07-10

สมัยที่พัฒนา Windows นั้น ดูเหมือนว่า Object Pascal with Delphi จะยอดเยี่ยมที่สุดจริง ๆ
 
GN⁺ 2023-07-10
ความเห็นจาก Hacker News

  • ถ้าใครเคยใช้ Delphi มาก่อน ก็น่าจะรู้จัก Lazarus อยู่แล้วพอสมควร จริง ๆ แล้ว Lazarus แทบจะเป็นการทำซ้ำแบบโอเพนซอร์ส และสามารถรัน/คอมไพล์แบบเนทีฟได้แทบทุกที่ รวมถึงบนบอร์ด ARM อย่าง Raspberry Pi
    แต่การติดตั้งไลบรารีอาจยุ่งยากอยู่บ้าง จึงมีการสร้าง FpcUp และต่อมาคือ FpcUpDeluxe เพื่อทำให้การติดตั้ง IDE, โมดูล และแอดออนที่น่าสนใจหลายตัวเป็นอัตโนมัติ
    https://wiki.freepascal.org/fpcupdeluxe
    ยังมีเดโมวิดเจ็ตแดชบอร์ดที่ทำขึ้นแบบเร่งด่วนด้วยวิดเจ็ตฟรีที่รวมมาใน FpcUpDeluxe ด้วย
    https://ibb.co/9bchx7T
    FpcUpDeluxe ใช้งานบน Alpine Linux ได้เช่นกัน โดยดาวน์โหลดเวอร์ชัน musl จากหน้ารุ่นออก ก็เลยเปิดความเป็นไปได้ในการใส่แดชบอร์ดลงบนระบบขนาดเล็กมากได้ โค้ดคอมไพล์เป็นเนทีฟบนหลายแพลตฟอร์มและทำงานได้รวดเร็ว โดยไม่ต้องใช้อินเทอร์พรีเตอร์หรือเว็บเบราว์เซอร์

    • พอพูดว่า “วิดเจ็ตฟรี” ก็เลยสงสัยว่ามีวิดเจ็ตแบบเสียเงินด้วยหรือเปล่า Qt5 มีวิดเจ็ตแถมมาเยอะจนรับมือแทบไม่ไหว ไม่แน่ใจว่า วิดเจ็ตพื้นฐานของ Lazarus มีข้อจำกัดมากไหม
      ครั้งสุดท้ายที่ได้ใช้ Lazarus กับ Delphi คือรู้สึกว่า Unicode ยังลำบาก และโดยรวมเหมือนตั้งต้นจากการสมมติว่าเป็น ASCII
    • ถ้าสนใจ Lazarus, Qt และซอฟต์แวร์ CAD 2D/3D ก็มีโปรเจกต์โอเพนซอร์สด้านการออกแบบและจำลองเรือที่เขียนใหม่จาก Delphi อยู่
      [0] https://github.com/markmal/freeship-plus-in-lazarus
      [1] http://web.archive.org/web/20160128212152/http://hydronship.net/index.php?lang=en
      [2] https://sourceforge.net/projects/freeship

  • ครั้งหนึ่งผมเคยใช้ Delphi/Pascal เป็นภาษาหลัก และตลอดช่วง 10~20 ปีที่ผ่านมา ก็ลองตามหาภาษาที่เหมาะกับตัวเอง Haxe ก็ใช้อยู่นานพอสมควร แต่สุดท้ายก็รู้สึกเหมือนติดกับดักแบบ “อันนั้นทำด้วยแมโครก็ได้” แมโครทำได้แทบทุกอย่างก็จริง แต่ถ้ามีมากพอ ทุกคนก็จะลงเอยด้วยการเขียนโปรแกรมด้วยภาษาขยายแมโครของตัวเอง
    JavaScript มีการปรับปรุงที่ดีเกิดขึ้นและยังต้องการอีกมาก แต่ตอนนี้ผมก็ยังทำงานฝั่งนั้นเยอะอยู่ หลายปีก่อนตอนเขียนโค้ดให้ AVR 8 บิต ผมได้กลับไปใช้ FreePascal อีกครั้งและสนุกมาก พอลองใช้ฟีเจอร์ใหม่ ๆ ก็รู้สึกว่าเป็นภาษาสมัยใหม่จริง ๆ และผมก็ชอบที่การเขียนโค้ดให้กับพื้นที่เล็ก ๆ ทำให้แทบไม่ใช้ไลบรารีมาตรฐาน ต้องสร้างโค้ดที่ต้องใช้ขึ้นมาเอง
    นั่นทำให้ผมหลีกเลี่ยงชั้นของความรกจากเนมสเปซเพื่อความเข้ากันได้ย้อนหลังที่ FreePascal สะสมมาตลอดหลายปี เช่น TList, TFPList, TFPGList, TFPGObjectList สิ่งที่น่าเสียดายที่สุดคือบนเป้าหมายที่ไม่มี FPU หรือไม่มีการอีมูเลชัน คอมไพเลอร์ไม่ยอมให้ใช้ constant floating-point expression ทั้งที่มันน่าจะคำนวณได้ตอนคอมไพล์จึงน่าจะรองรับได้
    พอไปใช้สภาพแวดล้อมอื่น ตอนนี้ผมกลับรู้สึกว่าการประกาศตัวแปรกลางฟังก์ชันไม่ได้เป็นข้อจำกัด และอยากได้การกำหนดสโคประดับฟังก์ชันย่อยด้วย begin/end กับ {} ไม่ได้ต่างกันมากนักสำหรับผม ตอนนี้ผมกลับชอบภาษาที่แยกตัวพิมพ์เล็กใหญ่ และมองว่าการไม่ใส่ตัวอักษรนำหน้าประเภทข้อมูลนั้นดีกว่า ซึ่งน่าจะเป็นเพราะตัวแก้ไขโค้ดพัฒนาไปมาก การเน้นไวยากรณ์และการ lint แบบเรียลไทม์ช่วยย้ายข้อมูลไปอยู่อีกชั้นหนึ่ง ลดความรกของข้อความลง
    ถ้ามี ภาษาผู้สืบทอดของ FreePascal ที่เริ่มต้นใหม่จริง ๆ ผมน่าจะตื่นเต้นมาก อยากได้ไลบรารีมาตรฐานใหม่ที่ใช้ฟีเจอร์สมัยใหม่เป็นพลเมืองชั้นหนึ่ง และถ้าเกษียณแล้ว บางทีผมอาจลองสร้างมันดู

    • begin/end กับ {} จริง ๆ แล้วไม่ได้มีความหมายเหมือนกัน {} ใช้นิยาม local scope แต่ begin/end ไม่ได้ทำแบบนั้น

  • ช่วงยุค 90 ผมเคยใช้ Delphi ทำงานอยู่หลายปีและชอบมันมาก แต่ก็เหนื่อยกับการที่ Borland และเจ้าของต่อ ๆ มาบริหารผลิตภัณฑ์กับตัวภาษาได้ผิดพลาดซ้ำแล้วซ้ำอีก Anders Hejlsberg เองก็ออกจาก Borland ไป Microsoft เพื่อสร้าง C# และส่วนตัวผมมองว่ามันเป็นภาษาและสถาปัตยกรรมที่คุ้มกับการลงทุนเวลามากกว่าเยอะ

    • การปล่อยแอปเดสก์ท็อป C# ให้แจกจ่ายได้อย่างเสถียรนั้น เมื่อเทียบกับ exe เดี่ยว ที่ Delphi/Lazarus สร้างได้แล้ว แทบจะเป็นฝันร้ายเต็มรูปแบบ

  • ทุกวันนี้ผมใช้ Pascal แบบสนุก ๆ เพราะข้อจำกัดด้านทรัพยากร สมัยก่อน Turbo Pascal 3.00A ของ Borland รันบน CP/M ได้ และมีทั้งเอดิเตอร์ คอมไพเลอร์ และไลบรารีครบภายใน 64KB
    มันเร็วพอสำหรับการใช้งานแบบโต้ตอบ และสร้างโค้ดที่ดีพอสำหรับทำยูทิลิตีระดับล่าง เกมง่าย ๆ หรือการแฮ็กจิปาถะได้ ผมไม่เคยใช้ Pascal ในสภาพแวดล้อมที่ใหญ่กว่าหรือทันสมัยกว่านั้น แต่ประสบการณ์ล่าสุดก็น่าพอใจมากจนยังไม่คิดจะตัดมันทิ้ง

    • Turbo Pascal และ Delphi ในยุคถัดมาคือช่วงเวลาที่ภาษาโปรแกรมทำให้ผมรู้สึกว่า "ใช่เลย" เป็นครั้งแรก สุดท้ายผมก็ไปทาง C และ C++ แต่ก็มีความรู้สึกอยากกลับไปใช้ภาษาที่แสดงออกได้ดีกว่าอยู่เสมอ
      ไม่เคยรู้มาก่อนว่ายังมี Pascal เวอร์ชันสมัยใหม่ให้ใช้อยู่ อาจถึงเวลาต้องกลับไปสานสัมพันธ์กับรักแรกอีกครั้ง
    • ถ้ายังไม่เคยลอง ก็ควรไปดู Free Pascal รองรับหลายแพลตฟอร์มมาก
      ถ้าต้องการ CP/M ก็ตรวจสอบได้ในเว็บไซต์ว่ารองรับหรือไม่ และถึงรองรับก็ไม่น่าแปลกใจ IDE แบบข้อความของมันคล้าย Turbo Pascal มากและเร็วราวสายฟ้า ตัวภาษามีความสามารถขั้นสูงมากกว่า Turbo Pascal เยอะ แต่ถ้าไม่อยากใช้ก็ไม่จำเป็นต้องใช้
      ตอนที่เคยลองทดสอบง่าย ๆ บน Windows ไบนารีที่ได้ก็เล็กมากเหมือน C โดยโปรแกรม hello world ธรรมดามีขนาดต่ำกว่า 50~60KB
    • อา ความคิดถึง Pascal สมัย TRS-80 Model III ผมเก็บเงินก้อนใหญ่ 80~100 ดอลลาร์ไปซื้อแพ็กเกจ Pascal 80 เวอร์ชัน New Classics มันแทบจะเป็น IDE ยุคแรก ๆ และถือว่าดีมากสำหรับมาตรฐานตอนนั้น http://www.trs-80.org/pascal-80/
      จำได้ว่ามันเป็นก้าวกระโดดครั้งใหญ่จากสภาพแวดล้อมพัฒนา M-III BASIC และแม้จะมี RAM แค่ 48KB เกมกับยูทิลิตีที่ผมเขียนเองก็ทำงานได้ดีพอสมควร ผมสงสัยว่าฐานโค้ด Pascal-80 ลงเอยอย่างไร คงไม่น่าจะดีกว่าเครื่องมือสมัยใหม่สำหรับฮาร์ดแวร์ย้อนยุค และอาจจะแย่กว่ามากด้วยซ้ำ “Oh Pascal!” คือหนังสือที่ผมใช้เรียนภาษานี้ และตอนนั้นก็ยังเป็นช่วงก่อนที่ Pascal จะถูกใช้เชิงพาณิชย์อีกหลายปี จึงคงมีตัวเลือกอื่นไม่มากนัก

  • มีบางเหตุผลที่ผมเห็นด้วยได้ยาก Object Pascal ไม่ใช่ภาษาสมัยใหม่ อาจจะใช่ในปี 1998 แต่หลังจากนั้นก็ไม่ได้พัฒนาไปมากนัก และการเปลี่ยนแปลงใหญ่ครั้งสุดท้ายก็คือ generics ซึ่งเข้ามาช้ากว่าภาษาอื่นแทบทั้งหมด
    FPC ก็ไม่ได้สร้างโค้ดที่เร็วเป็นพิเศษ และลักษณะของอ็อบเจ็กต์ใน Object Pascal ก็ไม่ได้เอื้อต่อ locality ด้วย มันเร็วกว่าภาษาสคริปต์ก็จริง แต่โดยทั่วไปมักช้ากว่าภาษาแบบคอมไพล์ล่วงหน้าทั่วไป แม้จะนับรวมภาษาที่มี garbage collection ด้วยก็ตาม
    ในทางกลับกัน ecosystem นั้นยอดเยี่ยม มีทั้งไลบรารีและเครื่องมือดี ๆ มากมาย โดยสิ่งที่โดดเด่นที่สุดคือ Lazarus ซึ่งเป็นโคลนของ Delphi คนที่ใช้ FPC หรือ Delphi ส่วนมากไม่ได้สนใจเรื่องทำให้ภาษาทันสมัยนัก แค่ทำงานให้เสร็จก็พอ แต่ผมไม่แน่ใจว่ามันจะดึงดูดนักพัฒนารุ่นใหม่ได้หรือไม่ เลยไม่รู้ว่าอนาคตจะเป็นอย่างไร

    • generics เข้ามาใน FPC ตั้งแต่ 17 ปีก่อน จึงห่างไกลจากคำว่าเป็นการเปลี่ยนแปลงล่าสุดมาก ถ้าจะนับการเพิ่มเข้ามาครั้งใหญ่ในช่วงหลัง ผมว่า anonymous functions กับ function references หรือก็คือ closures น่าจะเหมาะกว่า
      ประสิทธิภาพจริงก็เพียงพอ และถ้าหาคอขวดเจอก็สามารถปรับแต่งเพิ่มได้เท่าที่จำเป็น เมื่อเทียบกับ C++ การใช้คลาสแบบ “ระดับสูง” อาจยุ่งยากกว่าเล็กน้อย แต่ก็ไม่ได้เป็นไปไม่ได้
      ถ้าต้องการประสิทธิภาพพื้นฐานที่ดีโดยใช้ความพยายามน้อยที่สุด ก็มี LLVM backend ใหม่ด้วย เพียงแต่ต้องคอมไพล์ทั้ง runtime library และ FCL เป็นต้น ด้วย LLVM backend จึงต้องสร้างคอมไพเลอร์จากซอร์สเอง แต่ใช้เวลาไม่กี่นาที แลกกับคอมไพเลอร์ที่ช้าลงมาก และส่วนตัวผมไม่คิดว่าความต่างด้านประสิทธิภาพจะคุ้มขนาดนั้น
    • คุณประเมินมันต่ำไปหน่อย ผมเคยเห็นมันทำ benchmark ได้เร็วพอ ๆ กับ C++ ด้วยซ้ำ และในงานหลักของมันอย่าง แอป GUI แบบโลคัล ผมไม่เคยเห็นอะไรตอบสนองฉับไวขนาดนี้มาก่อน รวมถึงแอป GUI ของ C# ด้วย
      เพราะงั้นผมเลยอยากรู้ว่า benchmark ไหนที่ทำให้คุณสรุปว่ามันช้ากว่าความเป็นจริงประมาณ 50 เท่า
    • ผมไม่รู้เรื่อง FPC แต่ Delphi 7 เมื่อราว 10 ปีก่อน ในการแข่งขันเขียนโปรแกรมก็อยู่ระดับใกล้เคียงกับ C++ และเร็วกว่า Java ประมาณ 2~3 เท่า
      การแข่งขันเขียนโปรแกรมในที่นี้หมายถึงงานคำนวณอัลกอริทึมแบบใช้ CPU หนัก ๆ เธรดเดียว ระยะสั้นมาก แค่ 1~3 วินาทีต่อการรัน ซึ่งไม่เป็นมิตรกับ JIT และใช้ค่าคอมไพเลอร์/รันไทม์พื้นฐานโดยไม่มีไลบรารีภายนอกหรือการจูนเพิ่มเติม ตอนนั้นความเข้าใจทั่วไปคือใช้ C++/Pascal ไปเลย หรือถ้าเขียน Java แล้วเจอ “time limit exceeded” ก็เอาเฉลยยาว 200~300 บรรทัดไปเขียนใหม่เป็น C++ เพื่อให้ผ่าน
    • ความต่างที่ใหญ่ที่สุดระหว่าง Pascal กับ C++ คือ ประสบการณ์ของนักพัฒนา
      Pascal ใช้คอมไพเลอร์แบบ single-pass LL(1) จึงคอมไพล์ได้ในระดับมิลลิวินาที มอบประสบการณ์แบบ REPL ที่ Edit→Compile→Run เสร็จได้ภายใน 1 วินาที C/C++ ที่มีแมโครและใช้เวลาคอมไพล์ช้ากว่าจึงให้ประสบการณ์นักพัฒนาที่แย่กว่า และอย่างน้อยนั่นก็เป็นเหตุผลที่ผมเลือกเรียน Pascal แทน C และเลือก Delphi แทน C++
    • ผมไม่ค่อยเห็นด้วยอย่างแรงกับคำบอกว่า ecosystem ยอดเยี่ยม ผมทำงานกับ Pascal มาราว 10 ปี และมักหงุดหงิดกับ การขาดแคลนไลบรารีสมัยใหม่ สุดท้ายจึงต้องสร้างวิธีแก้เอง หรือไม่ก็ต้องล้มเลิกไอเดียนั้นไปเลย

  • ไม่เข้าใจว่าทำไมต้องทำแบบนั้นด้วย ภาษารุ่นเก่าควรคงอยู่เพื่อรองรับระบบเลกาซีก็จริง แต่ไม่ค่อยเห็นความหมายของการยัดฟีเจอร์สมัยใหม่พวกนั้นเข้าไปในภาษาเก่าแบบฝืน ๆ
    ผมใช้ Java เยอะ แต่พูดตามตรงว่าแทบทุกฟีเจอร์ตั้งแต่ Java 8 เป็นต้นมา ไม่ควรถูกเพิ่มเข้ามาด้วยซ้ำ เช่น lambda ใน Java ก็แทบจะเป็นการปะผุเสียมากกว่า
    ถ้าต้องการฟีเจอร์สมัยใหม่ก็ใช้ภาษาสมัยใหม่ไปเลย ถ้าอยากอยู่ใน ecosystem ของ Java ก็ใช้ Kotlin ได้ Pascal นี่พูดตรง ๆ ว่าหลายสิบปีแล้วที่ไม่ได้เห็น และครั้งสุดท้ายที่เขียนก็ตั้งแต่ยุค 1980 เลยพูดได้แต่เรื่อง Java แต่การเพิ่มรายการฟีเจอร์แบบนั้นให้ Pascal มันดูน่าขำ

    • lambda เป็นการปะผุเหรอ? หมายความว่าคุณคิดว่าการสร้าง anonymous class ที่มีเมธอดเดียวมันดีกว่าจริง ๆ เหรอ?
    • ใน Java การทำงานข้ามภาษาทำได้ง่าย เลยทำให้ตัวเลือกอย่าง Kotlin เลือกใช้ได้ง่ายกว่า Clojure ก็เหมือนกัน แต่ถ้าคุณใช้ C++ อยู่ ก็ไม่มีเส้นทางอัปเกรดไปเป็นอย่างอื่นได้ง่าย ๆ
      ถึงอย่างนั้น การยัดฟีเจอร์สมัยใหม่เข้าไปก็ยังมีคุณค่า คุณอาจเลือกไม่เริ่มโปรเจ็กต์ใหม่ด้วย C++ แล้วไปใช้ภาษาสมัยใหม่อย่าง Rust แทนได้ แต่ โค้ด C++ ที่เขียนไว้แล้วนับล้านบรรทัดสามารถปรับปรุงได้ด้วยฟีเจอร์สมัยใหม่ แค่ดู C++11 ก็พอว่ามันเปลี่ยนเกมแค่ไหน
    • ถ้าอย่างนั้นก็ต้องเปลี่ยนภาษาโปรแกรมให้บ่อยขึ้นมาก การเพิ่มและผสานฟีเจอร์ใหม่ที่พิสูจน์แล้วว่าคุ้มค่าเพื่อชะลอกระบวนการนี้ก็ดูสมเหตุสมผล
    • จนกระทั่งไม่นานมานี้ Java แทบไม่มีอะไรเหนือกว่า Delphi เมื่อ 15 ปีก่อนเลย ถ้าไม่นับ ecosystem ที่ใหญ่โตเกินจริง แน่นอนว่า ecosystem นั้นชนะทุกอย่าง
      ภาษา Java สร้าง boilerplate code มหาศาลจากการตัดสินใจใช้ไลบรารีแทนฟีเจอร์ของภาษา และผมคิดว่าทิศทางนั้นผิด สิ่งที่ทำได้ใน Python, Lisp, Haskell ก็ทำได้ใน Java หมด แต่ตามนิยามแล้วใน brainf*ck ก็ทำได้เหมือนกัน ความซับซ้อนของวิธีแก้แบบ Java ในโลกจริงสูงกว่าภาษาที่มีฟีเจอร์มากกว่า และสุดท้ายก็มักต้องสร้างฟีเจอร์ภาษาเหล่านั้นขึ้นมาใหม่แบบที่พัง ๆ หน่อย หรือไม่ก็ดึง dependency จำนวนมากมาแทน ไม่ว่าแบบไหนก็แค่เพิ่มพื้นผิว API ที่ต้องเรียนรู้
    • ภาษาบน JVM ที่แข่งขันได้เพิ่งมีจริง ๆ ในช่วงไม่กี่ปีมานี้เอง Scala เป็นทางตัน Clojure ก็เกือบจะเป็นกระแสชั่วคราว ส่วน Rhino/JS ก็มีความทะเยอทะยานจำกัดมาก
      การพัฒนาของ Java ทำให้ JVM ยังคงมีความเกี่ยวข้องต่อไปและต้าน DotNet ได้ ซึ่งเมื่อดูจากประวัติของ Microsoft แล้วก็นับว่าเป็นเรื่องดี

  • คนมักมองข้ามกัน แต่ ecosystem แบบฝังตัวของ Ada มีข้อได้เปรียบในด้านความ成熟ของการวิเคราะห์แบบสถิต, การดีบัก, และการรองรับแพลตฟอร์มเป้าหมาย

    • ผมคิดว่า Ada ถูกประเมินต่ำไปเสมอ ส่วนตัวชอบฟีเจอร์อย่างความปลอดภัยของหน่วยความจำ, โมเดล concurrency มาตรฐาน, การรองรับชนิดข้อมูลหน่วยและการวัด, และการ precompile
      ไวยากรณ์ที่คล้าย Pascal ของ Ada อาจดูยืดยาว แต่ไม่ได้อ่านยาก VHDL ก็อิงไวยากรณ์ของ Ada ด้วย จึงอาจง่ายกว่าสำหรับคนที่ใช้สองภาษานี้ร่วมกัน
      Swift ก็มีบางอย่างตามนี้ และยังเพิ่มฟีเจอร์ที่สะดวกอย่าง closure, automatic reference counting, type inference เข้าไปด้วย ส่วนเรื่องชนิดข้อมูลการวัดไม่แน่ใจ แต่ก็ดูเหมือนจะทำได้ เพียงแต่ตอนนี้ยังไม่เห็น HDL แบบ Swift
    • สงสัยว่า Ada รองรับ เป้าหมาย Android และ iOS แล้วหรือยัง ครั้งสุดท้ายที่ดูเหมือนไม่มีวิธีชัดเจนในการบิลด์สำหรับ NDK
    • มันไม่ใช่ตัวเลือกที่เป็นมิตรที่สุดสำหรับการเริ่มต้นบน macOS

  • Pascal จริง ๆ แล้วค่อนข้างดีและประสิทธิภาพก็โอเคด้วย เป็นภาษาที่สองที่ผมเรียนต่อจาก Basic ตอนมัธยมปลาย
    ผมไม่เข้าใจว่าทำไมวงการต้องถอยหลังไปหา Python, Ruby, Java, JavaScript ในช่วงปลายยุค 90 และต้นยุค 2000

    • เพิ่งดูงานบรรยายเกี่ยวกับเรื่องนี้มาไม่นาน: https://www.youtube.com/watch?v=Tml94je2edk
      เขาอธิบายว่าทำไมภาษาที่มี dynamic typing อย่าง Python, Ruby, JS ถึงได้รับความนิยมในยุค 90 เพราะมันให้วงจรป้อนกลับที่รวดเร็วตอนสร้างเว็บไซต์ และไม่ต้องพึ่ง IDE หรือคอมไพเลอร์ ตอนนั้น IDE กับคอมไพเลอร์ทั้งช้าและหลายครั้งก็ไม่ฟรี
      อีกอย่าง ตอนนั้นผู้ใช้ยังต่ออินเทอร์เน็ตผ่านโมเด็ม 56k กันอยู่ ดังนั้นการแลกเวลาในการพัฒนาเพื่อให้ได้ประสิทธิภาพเพิ่มขึ้นจึงไม่ค่อยคุ้ม ในงานบรรยายยังมีประเด็นน่าสนใจอีกมากเกี่ยวกับการที่รูปแบบการพัฒนาเปลี่ยนไปอย่างไรในช่วง 10-20 ปีที่ผ่านมา และทำไมกระแสถึงเริ่มกลับไปหา static typing
    • คอมพิวเตอร์เร็วขึ้นและหน่วยความจำก็มากขึ้น ก็เลยต้องหาวิธีใช้มันไง ;-)
      อีกอย่างคือเว็บเบราว์เซอร์กลายเป็นแพลตฟอร์มการเขียนโปรแกรมยอดนิยม และส่วนใหญ่ก็ใช้ JavaScript จนถึงตอนนี้นอกจากส่วนของเบราว์เซอร์แล้ว เรายังพยายามยัด ระบบปฏิบัติการเต็มรูปแบบ เข้าไปในเว็บเบราว์เซอร์ด้วย และ Chrome ก็เข้าใกล้จุดนั้นมากแล้ว

  • โปรเจ็กต์แรกของผมตอนเรียนมหาวิทยาลัยปีหนึ่งคือโปรแกรมจำลองลิฟต์ที่เขียนด้วย Pascal และใช้กราฟิกแบบข้อความ เมื่อเทียบกับภาษาตระกูล C แล้ว Pascal มีบางอย่างที่ สง่างาม อยู่ในตัว เลยทำให้เขียนได้อย่างเพลิดเพลิน
    เพราะอย่างนั้นเดี๋ยวนี้ผมเลยสนุกกับ Nim มาก และเท่าที่รู้ Nim ได้รับอิทธิพลไม่ใช่แค่จาก Ada กับ Python แต่ยังมาจากภาษาตระกูล Wirth อย่าง Pascal, Modula-3, Oberon, Delphi ด้วย

  • Pascal ไม่ได้แย่ขนาดนั้น และจริง ๆ แล้วผมคิดว่ามันมีข้อดีเหนือกว่าภาษาโปรแกรมสมัยใหม่บางภาษาเสียอีก แน่นอนว่ามันไม่สมบูรณ์แบบและก็มีข้อเสียอยู่
    บางครั้งผมใช้ Pascal กับ BASIC สำหรับเขียนโปรแกรมบน DOS และอย่างน้อยสำหรับงานแบบนั้น Pascal ก็ดูโอเค C ก็ถูกใช้กับการเขียนโปรแกรมบน DOS เหมือนกัน แต่โดยเฉพาะใน real mode มันดูไม่ค่อยเหมาะเท่าไร
    สำหรับการเขียนโปรแกรมบน Linux โดยทั่วไปผมชอบ C มากกว่า แต่ก็ใช้ PostScript ด้วย ผมคิดว่าทั้ง C และ PostScript ต่างก็มีข้อดีเมื่อเทียบกับภาษาสมัยใหม่บางภาษา Pascal ก็เอาไปใช้กับโปรแกรมอื่นได้เช่นกัน และแม้แต่ TeX ก็ยังเขียนด้วย Pascal

    • อยากรู้ว่าคุณใช้ PostScript ทำอะไรบ้าง เวลาเห็นคนใช้มันนอกเหนือจากงานพิมพ์นี่น่าสนใจดี