2 คะแนน โดย GN⁺ 2023-08-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้เขียนแบ่งปันเส้นทางการก้าวออกจาก Haskell ซึ่งเป็นภาษาการเขียนโปรแกรมเชิงฟังก์ชันที่เขาใช้มาในฐานะวิศวกรซอฟต์แวร์ตลอด 10 ปี
  • ผู้เขียนหลงใหลในความสามารถของ Haskell ที่ช่วยให้เข้าใจโค้ดได้ในเชิงสัญลักษณ์และเชิงพีชคณิต รวมถึงระบบชนิดข้อมูลที่แข็งแกร่ง
  • ระบบชนิดข้อมูลของ Haskell เปิดให้มีการตรวจสอบชนิดข้อมูลอย่างเข้มงวดโดยไม่จำกัดมากเกินไปหรือส่งสัญญาณรบกวนเกินจำเป็น ทำให้เขียนและดูแลโค้ดได้ง่ายขึ้น
  • ผู้เขียนชื่นชมความสามารถของ Haskell ในการใช้ชนิดข้อมูลเพื่อแสดงความไม่เปลี่ยนแปลงของข้อมูล ซึ่งทำให้คอมไพเลอร์ช่วยตรวจตราตรรกะซ้ำอีกชั้น เพิ่มความปลอดภัยและความถูกต้องของโค้ด
  • แม้จะมีข้อดีเหล่านี้ ผู้เขียนก็ถอยห่างจาก Haskell ด้วยเหตุผลหลัก 3 ประการ ได้แก่ ความอยากได้ความแปลกใหม่ด้านสไตล์ เครื่องมือที่ใช้งานไม่คล่องตัว และการเปลี่ยนแปลงอย่างต่อเนื่อง
  • ความแปลกใหม่ด้านสไตล์หมายถึงแนวโน้มของชุมชน Haskell ที่ชอบทดลอง abstraction ใหม่ ๆ ซึ่งแม้จะสร้างนวัตกรรมได้ แต่ก็อาจทำให้การดูแลโค้ดยากขึ้น
  • ผู้เขียนประเมินว่าเครื่องมือของ Haskell "ใช้ได้" แต่ระบุว่าไม่มีเครื่องมือใดที่ใช้งานง่ายและเสถียรได้เท่ากับ cargo ของ Rust
  • การเปลี่ยนแปลงอย่างต่อเนื่องของ Haskell โดยเฉพาะการแก้ไขที่ทำลายความเข้ากันได้แบบย้อนหลังเป็นระยะ ๆ ทำให้แรงเสียดทานในการใช้งานภาษาเพิ่มขึ้น
  • แม้จะห่างจาก Haskell แล้ว ผู้เขียนก็ยังยอมรับจุดแข็งของมัน ทั้งความสามารถในการรีแฟกเตอร์โค้ดในเชิงพีชคณิต ระบบชนิดข้อมูล และระบบนิเวศของไลบรารีแบบประกาศ
  • ผู้เขียนสรุปว่าการจะใช้ Haskell หรือไม่นั้นขึ้นอยู่กับเป้าหมายของแต่ละคน และแนะนำให้เรียนรู้ Haskell เพื่อพัฒนาตนให้เป็นโปรแกรมเมอร์ที่ดีขึ้น แต่ก็เตือนให้ระมัดระวังหากจะใช้เป็นภาษาหลัก เนื่องจากความท้าทายที่เขาอธิบายไว้

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

 
GN⁺ 2023-08-26
ความเห็นจาก Hacker News
  • ชุมชน Haskell เป็นที่รู้จักจากการให้ความสำคัญกับการเรียนรู้อย่างมาก และการสร้างบรรยากาศแห่งความอยากรู้อยากเห็นกับการแบ่งปันความรู้
  • อย่างไรก็ตาม ชุมชนมักมีปัญหาในการละทิ้งไอเดียหลังจากทดลองแล้ว ทำให้โค้ดเบส Haskell ในงานระดับมืออาชีพกลายเป็นสิ่งที่สับสน
  • เครื่องมือของ Haskell มักถูกวิจารณ์ แต่ก็มีคนโต้แย้งว่าภาษาโปรแกรมส่วนใหญ่ก็มีเครื่องมือที่ด้อยกว่าเช่นกัน
  • เครื่องมือของ Haskell มีความสามารถเฉพาะตัวอย่าง Hoogle ซึ่งได้รับการยอมรับอย่างมากเพราะมีประโยชน์มาก
  • พัฒนาการของ Haskell และ GHC ซึ่งเป็น implementation แบบเปิดเพียงตัวเดียวที่ถือว่าสมเหตุสมผล ก็ถูกวิจารณ์เพราะมีการเปลี่ยนแปลงและความไม่สอดคล้องอย่างต่อเนื่อง
  • การผูกโยงกันระหว่าง GHC กับเวอร์ชันเฉพาะของไลบรารีมาตรฐานอย่าง base ถูกมองว่าเป็นปัญหา เพราะบังคับให้ต้องเปลี่ยน dependencies ทุกครั้งที่มี GHC เวอร์ชันใหม่ออกมา
  • การหมดความสนใจใน Haskell ของผู้เขียนมีสาเหตุหลักสามอย่าง คือความแปลกใหม่เชิงสไตล์ เครื่องมือที่ใช้งานไม่ถนัด และการเปลี่ยนแปลงอย่างต่อเนื่อง
  • เอกสารประกอบและเครื่องมือของ Haskell ทำงานด้วยได้ยาก และการที่ชุมชนเปลี่ยนจาก Cabal ไปเป็น Stack แล้วกลับมาที่ Cabal อีกครั้ง ก็ถูกมองว่าเป็นสัญญาณของการพัฒนา
  • ภาษาโปรแกรมอื่น ๆ ได้นำองค์ประกอบของการเขียนโปรแกรมเชิงฟังก์ชันเข้ามาผสาน ทำให้ดูน่าสนใจกว่าสำหรับนักพัฒนาบางคน
  • นักพัฒนาบางส่วนย้ายจาก Haskell ไปใช้ F# เพราะมองว่าการเขียนโค้ดง่ายกว่า
  • Haskell ถูกมองว่าเรียนรู้ยาก และไลบรารีของมันก็มักล้าสมัยหรือทำมาไม่สมบูรณ์
  • ประสิทธิภาพของ Haskell ถูกวิจารณ์ โดยการประเมินค่าแบบขี้เกียจทำให้เกิดปัญหาด้านหน่วยความจำและประสิทธิภาพที่ช้า
  • สำหรับนักพัฒนา Haskell โอกาสงานถูกมองว่ามีจำกัด เพราะภาษานี้มีความเฉพาะทางสูง
  • การดีบักใน Haskell ถูกอธิบายว่าเป็นเรื่องท้าทาย เนื่องจากความซับซ้อนของภาษา
  • Scala ถูกมองว่าเป็นทางเลือกที่ดีแทน Haskell เพราะให้ข้อดีจากทั้งสองฝั่ง
  • บางคนตั้งคำถามถึงความจำเป็นของฟีเจอร์ภาษาขั้นสูงในงานวิศวกรรมซอฟต์แวร์ทั่วไปในแต่ละวัน
  • มีมุมมองว่าการที่ Haskell มุ่งเน้นงานวิจัยและการแสวงหาทางวิชาการ อาจขัดกับความต้องการของการเขียนโปรแกรมเชิงปฏิบัติ
  • โพสต์นี้เสนอว่าควรมีวิธีแยกฟีเจอร์เชิงทดลองออกจากฟีเจอร์ที่เสถียรใน Haskell
  • ผู้เขียนบอกว่าตนไม่ได้รู้สึกถูกกดดันให้ใช้ฟีเจอร์ type ขั้นสูงใหม่ ๆ ใน Haskell และแนะนำให้พัฒนาสัญชาตญาณว่าควรใช้ type ที่ซับซ้อนมากแค่ไหน