การเขียนโปรแกรมเชิงฟังก์ชั่นช่วยเพิ่มช่องว่างระหว่างปัญหาและแนวทางแก้ไขหรือไม่ [ปิด]

เนื่องจากภาษาเครื่อง (เช่น0110101000110101) ภาษาคอมพิวเตอร์มีวิวัฒนาการโดยทั่วไปในรูปแบบที่เป็นนามธรรมสูงกว่าโดยทั่วไปทำให้ง่ายต่อการเข้าใจรหัสเมื่อมันถูกนำไปใช้กับปัญหา แอสเซมเบลอร์เป็นนามธรรมผ่านรหัสเครื่อง C เป็นนามธรรมเหนือแอสเซมเบลอร์ ฯลฯ

การออกแบบเชิงวัตถุดูเหมือนว่าจะดีมากที่ช่วยให้เราสามารถจำลองปัญหาในแง่ของวัตถุเช่นปัญหาของระบบการลงทะเบียนหลักสูตรมหาวิทยาลัยสามารถทำแบบจำลองกับCourseชั้นStudentเรียนคลาส ฯลฯ จากนั้นเมื่อเราเขียนวิธีการแก้ปัญหา ในภาษา OO เรามีคลาสที่คล้ายกันซึ่งได้รับความรับผิดชอบและโดยทั่วไปมีประโยชน์สำหรับการออกแบบโดยเฉพาะอย่างยิ่งสำหรับการทำให้โค้ดเป็นโมดูล ถ้าฉันให้ปัญหานี้แก่ทีมอิสระ 10 คนที่แก้ปัญหาด้วยวิธี OO โดยทั่วไป 10 วิธีแก้ปัญหาจะมีชั้นเรียนที่เกี่ยวข้องกับปัญหาที่เหมือนกัน อาจมีความแตกต่างมากมายเมื่อคุณเริ่มมีเพศสัมพันธ์และการโต้ตอบของคลาสเหล่านั้นดังนั้นจึงไม่มีสิ่งเช่น "ศูนย์ช่องว่างการเป็นตัวแทน"

ประสบการณ์การใช้งานฟังก์ชั่นการเขียนโปรแกรมของฉันมี จำกัด มาก (ไม่มีการใช้งานจริงในโลกมีเพียงโปรแกรมประเภท Hello World) ฉันล้มเหลวในการดูว่าภาษาดังกล่าวอนุญาตให้ทำแผนที่โซลูชั่น FP ได้อย่างง่ายดายเพื่อแก้ไขปัญหา (ด้วยช่องว่างที่เป็นตัวแทนต่ำ) ในแบบที่ภาษา OO ทำอย่างไร

ฉันเข้าใจถึงข้อดีของ FP ที่เกี่ยวกับการเขียนโปรแกรมพร้อมกัน แต่ฉันขาดอะไรไปหรือ FP ไม่ได้ลดช่องว่างในการเป็นตัวแทน (ทำให้การแก้ปัญหาเข้าใจง่ายขึ้น)?

อีกวิธีที่จะถามสิ่งนี้: รหัส FP ของ 10 ทีมที่แตกต่างกันในการแก้ปัญหาในโลกแห่งความจริงเดียวกันนั้นมีอะไรเหมือนกันมากมายไหม?

จากวิกิพีเดียเกี่ยวกับสิ่งที่เป็นนามธรรม (วิทยาการคอมพิวเตอร์) (เหมืองที่เน้น)

ภาษาเขียนโปรแกรมการทำงานโดยทั่วไปแสดงแนวคิดที่เกี่ยวข้องกับฟังก์ชั่นเช่นนามธรรมแลมบ์ดา (ทำให้ระยะในการทำงานของตัวแปรบางก), ฟังก์ชั่นขั้นสูง (พารามิเตอร์ฟังก์ชั่น) วงเล็บนามธรรม (ทำให้ระยะเวลาในการทำงานของตัวแปร a)

ช่องว่างในการดำเนินการอาจเพิ่มขึ้นได้เนื่องจากปัญหาบางอย่างในโลกแห่งความเป็นจริงนั้นไม่ได้ถูกสร้างแบบจำลองอย่างง่ายดายด้วยนามธรรมดังกล่าว

อีกวิธีหนึ่งที่ฉันเห็นการลดช่องว่างในการดำเนินการคือการติดตามองค์ประกอบโซลูชันกลับไปที่ปัญหา 0'และ1ในรหัสเครื่องเป็นเรื่องยากมากที่จะตรวจสอบย้อนกลับในขณะที่Studentระดับง่ายต่อการตรวจสอบย้อนกลับ ไม่ใช่คลาส OO ทั้งหมดที่ติดตามไปยังพื้นที่ปัญหาได้อย่างง่ายดาย แต่มีอยู่จำนวนมากที่ต้องทำ

FP abstractions ไม่จำเป็นต้องอธิบายเพื่อหาว่าพื้นที่ส่วนใดของปัญหาที่พวกเขากำลังแก้ไขอยู่ (นอกเหนือจากปัญหาทางคณิตศาสตร์ )ตกลง - ฉันทำได้ดีในส่วนนี้ หลังจากดูตัวอย่างอื่น ๆ อีกมากมายฉันเห็นว่า abstractions ของ FP มีความชัดเจนมากสำหรับส่วนต่าง ๆ ของปัญหาที่แสดงในการประมวลผลข้อมูล

คำตอบที่ได้รับการยอมรับสำหรับคำถามที่เกี่ยวข้องสามารถใช้ UML สร้างแบบจำลองโปรแกรมการทำงานได้หรือไม่? - กล่าวว่า "โปรแกรมเมอร์ที่ทำงานไม่ได้ใช้งานไดอะแกรมมากนัก" ฉันไม่สนใจว่ามันจะเป็น UML หรือเปล่า แต่มันทำให้ฉันสงสัยว่า FP abstractions ง่ายต่อการเข้าใจ / สื่อสารถ้าไม่มีไดอะแกรมที่ใช้กันอย่างแพร่หลาย (สมมติว่าคำตอบนี้ถูกต้อง) อีกครั้งระดับการใช้งาน / การทำความเข้าใจ FP ของฉันเป็นเรื่องเล็กน้อยดังนั้นฉันจึงไม่จำเป็นต้องเข้าใจไดอะแกรมในโปรแกรม FP อย่างง่าย

การออกแบบ OO มีฟังก์ชั่น / คลาส / แพ็กเกจระดับของสิ่งที่เป็นนามธรรมด้วยการห่อหุ้ม (การควบคุมการเข้าถึงการซ่อนข้อมูล) ในแต่ละครั้งซึ่งทำให้การจัดการความซับซ้อนง่ายขึ้น องค์ประกอบเหล่านี้ช่วยให้สามารถแก้ไขปัญหาและแก้ไขปัญหาได้ง่ายขึ้น

คำตอบมากมายพูดถึงวิธีการวิเคราะห์และออกแบบใน FP ในลักษณะที่คล้ายคลึงกับ OO แต่ไม่มีใครอ้างถึงสิ่งใดในระดับสูง (พอลอ้างถึงสิ่งที่น่าสนใจ แต่อยู่ในระดับต่ำ) ฉันทำ Googling มากเมื่อวานนี้และพบว่ามีการสนทนาที่น่าสนใจ ต่อไปนี้มาจากRefactoring Functional Programs โดย Simon Thompson (2004) (เหมืองที่เน้น)

ในการออกแบบระบบเชิงวัตถุนั้นจะต้องดำเนินการเพื่อให้ได้รับการออกแบบที่จะนำหน้าการเขียนโปรแกรม การออกแบบจะถูกเขียนโดยใช้ระบบเช่น UML ซึ่งได้รับการสนับสนุนในเครื่องมือเช่น Eclipse โปรแกรมเมอร์เริ่มต้นอาจเรียนรู้วิธีการออกแบบภาพโดยใช้ระบบเช่น BlueJ งานเกี่ยวกับระเบียบวิธีที่คล้ายกันสำหรับการเขียนโปรแกรมการทำงานมีรายงานในFAD: การวิเคราะห์และการออกแบบฟังก์ชั่นแต่มีงานอื่นเล็กน้อย อาจมีสาเหตุหลายประการ

• โปรแกรมการทำงานที่มีอยู่มีขนาดที่ไม่ต้องการการออกแบบ โปรแกรมการทำงานหลายโปรแกรมมีขนาดเล็ก แต่โปรแกรมอื่น ๆ เช่น Glasgow Haskell Compiler นั้นมีความสำคัญ

• โปรแกรมที่ใช้งานได้จำลองโมเดลโดเมนแอปพลิเคชันโดยตรงซึ่งทำให้การออกแบบไม่เกี่ยวข้อง ในขณะที่ภาษาที่ใช้งานได้นั้นมีรูปแบบนามธรรมที่ทรงพลังมากมายมันเป็นเรื่องยากที่จะโต้แย้งว่าสิ่งเหล่านี้มีรูปแบบนามธรรมที่จำเป็นทั้งหมดในการสร้างแบบจำลองโลกแห่งความจริง

• โปรแกรมการทำงานถูกสร้างขึ้นเป็นชุดต้นแบบของการพัฒนา

ในวิทยานิพนธ์ระดับปริญญาเอกที่อ้างถึงข้างต้นประโยชน์ของการใช้วิธีการวิเคราะห์และการออกแบบ (ADM) เป็นโครงร่างที่เป็นอิสระจากกระบวนทัศน์ แต่มีการโต้แย้งว่า ADM ควรสอดคล้องกับกระบวนทัศน์การนำไปปฏิบัติ นั่นคือ OOADM ทำงานได้ดีที่สุดสำหรับการเขียนโปรแกรม OO และใช้ไม่ได้กับกระบวนทัศน์อื่นเช่น FP นี่เป็นคำพูดที่ดีมากที่ฉันคิดว่าการถอดความสิ่งที่ฉันเรียกว่า

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

นี่คือชุดของไดอะแกรมที่เสนอโดย FAD:

• ฟังก์ชั่นการพึ่งพาแผนภาพซึ่งนำเสนอฟังก์ชั่นกับผู้ที่จะใช้ในการดำเนินงานของตน;
• พิมพ์แผนภาพพึ่งพาซึ่งให้บริการเดียวกันสำหรับประเภท; และ,
• โมดูลแผนภาพการพึ่งพาซึ่งนำเสนอมุมมองของสถาปัตยกรรมโมดูลของระบบ

มีกรณีศึกษาในหัวข้อ 5.1 ของวิทยานิพนธ์ FAD ซึ่งเป็นระบบที่จะทำการผลิตข้อมูลที่เกี่ยวข้องกับลีกฟุตบอล (ฟุตบอล) โดยอัตโนมัติ ความต้องการใช้งานได้ 100% เช่นผลฟุตบอลอินพุทสร้างตารางลีกตารางคะแนนตารางการเข้าร่วมถ่ายโอนผู้เล่นระหว่างทีมการอัพเดทข้อมูลหลังผลการแข่งขันใหม่ ฯลฯ ไม่ต้องพูดถึงว่า FAD ทำงานอย่างไรเพื่อแก้ปัญหาความต้องการที่ไม่ใช่หน้าที่ นอกเหนือจากที่ระบุว่า "ควรอนุญาตให้มีฟังก์ชั่นใหม่ในราคาประหยัด" ซึ่งเป็นสิ่งที่แทบเป็นไปไม่ได้ในการทดสอบ

น่าเศร้าที่นอกเหนือจาก FAD ฉันไม่เห็นการอ้างอิงที่ทันสมัยสำหรับการสร้างแบบจำลองภาษา (ภาพ) ที่เสนอให้กับ FP UML เป็นกระบวนทัศน์อื่นดังนั้นเราจึงควรลืม

ข้อมูลพื้นฐานนั้นมีโครงสร้างเหมือนกันในทุกกระบวนทัศน์ คุณจะมี a Student, a Course, ฯลฯ ไม่ว่าจะเป็นวัตถุ, struct, บันทึกหรืออะไรก็ตาม ความแตกต่างกับ OOP ไม่ใช่วิธีการจัดโครงสร้างข้อมูล แต่เป็นวิธีการจัดโครงสร้างของฟังก์ชัน

ฉันหาโปรแกรมที่ใช้งานได้จริงตรงกับที่ฉันคิดเกี่ยวกับปัญหามากขึ้น ตัวอย่างเช่นในการวางแผนกำหนดเวลาเรียนสำหรับภาคการศึกษาถัดไปคุณคิดถึงสิ่งต่าง ๆ เช่นรายการหลักสูตรที่นักเรียนทำเสร็จหลักสูตรในหลักสูตรปริญญาของนักศึกษาหลักสูตรที่เปิดสอนในภาคเรียนนี้ ไม่ขัดแย้ง ฯลฯ

ทันใดนั้นมันยังไม่ชัดเจนว่าคลาสใดควรสร้างและเก็บรายการทั้งหมดเหล่านี้ แม้แต่น้อยดังนั้นเมื่อคุณมีชุดค่าผสมที่ซับซ้อนของรายการเหล่านี้ อย่างไรก็ตามคุณต้องเลือกหนึ่งชั้น

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

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

เมื่อฉันเรียนวิชาจาวาเมื่อหลายปีก่อนเราคาดหวังว่าจะแสดงวิธีแก้ปัญหาให้กับชั้นเรียนทั้งหมดดังนั้นฉันจึงได้เห็นว่าผู้คนคิดอย่างไร วิธีแก้ปัญหาอย่างมีเหตุผล ฉันคาดหวังอย่างเต็มที่ถึงวิธีแก้ปัญหาเพื่อจัดกลุ่มโซลูชันทั่วไปสามหรือสี่ข้อ แต่ฉันดูเมื่อนักเรียน 30 คนแก้ปัญหาด้วยวิธีที่ต่างกันทั้งหมด 30 วิธี

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

ภาษาทางเทคนิคที่รมย์เขียนโปรแกรมการทำงานเป็นคณิตศาสตร์ ดังนั้นปัญหาที่เหมาะสมที่สุดในการแก้ปัญหาโดยใช้ฟังก์ชั่นการเขียนโปรแกรมนั้นเป็นปัญหาทางคณิตศาสตร์เป็นหลัก โดยคณิตศาสตร์ฉันไม่ได้หมายถึงคณิตศาสตร์ชนิดที่คุณเห็นในโซลูชันทางธุรกิจเช่นการบวกและการลบ แต่ฉันกำลังพูดถึงประเภทของคณิตศาสตร์ที่คุณอาจเห็นใน Math Overflow หรือประเภทของคณิตศาสตร์ที่คุณจะเห็นในเครื่องมือค้นหาของ Orbitz (เขียนเป็นภาษา Lisp)

การวางแนวนี้มีการแยกส่วนที่สำคัญสำหรับโปรแกรมเมอร์ที่ทำงานซึ่งพยายามแก้ปัญหาการเขียนโปรแกรมในโลกแห่งความจริง:

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

2. โปรแกรมเชิงวัตถุมักถูกสร้างขึ้นจากบนลงล่าง การออกแบบชั้นเรียนถูกสร้างขึ้นและมีการกรอกรายละเอียดโปรแกรมการทำงานมักถูกสร้างขึ้นจากล่างขึ้นบนเริ่มต้นด้วยฟังก์ชั่นขนาดเล็กที่มีรายละเอียดที่รวมเข้ากับฟังก์ชั่นระดับสูง

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

4. โปรแกรมเชิงวัตถุสามารถเหมาะสมกับโดเมนของธุรกิจได้มากกว่าเนื่องจากคลาสข้อความระหว่างวัตถุและรูปแบบซอฟต์แวร์ทั้งหมดนั้นมีโครงสร้างที่แมปกับโดเมนธุรกิจจับภาพข่าวกรองธุรกิจและเอกสาร

5. เนื่องจากซอฟต์แวร์ที่ใช้งานได้จริงทั้งหมดสร้างผลข้างเคียง (I / O) ภาษาการเขียนโปรแกรมที่ใช้งานได้ล้วนต้องใช้กลไกในการสร้างผลข้างเคียงในขณะที่ยังคงบริสุทธิ์ทางคณิตศาสตร์ (monads)

6. โปรแกรมการทำงานสามารถพิสูจน์ได้อย่างง่ายดายมากขึ้นเนื่องจากลักษณะทางคณิตศาสตร์ของพวกเขา ระบบประเภทของ Haskell สามารถค้นหาสิ่งต่าง ๆ ได้ในเวลารวบรวมซึ่งภาษา OO ส่วนใหญ่ไม่สามารถทำได้

และอื่น ๆ เช่นเดียวกับหลายสิ่งในการคำนวณภาษาเชิงวัตถุและภาษาเชิงหน้าที่มีการแลกเปลี่ยนที่แตกต่างกัน

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

ฉันต้องการเน้นในแง่มุมที่ฉันพบว่าสำคัญและไม่ได้กล่าวถึงในคำตอบอื่น ๆ

ก่อนอื่นฉันคิดว่าช่องว่างในการเป็นตัวแทนระหว่างปัญหาและวิธีแก้ปัญหาอาจอยู่ในใจของโปรแกรมเมอร์มากขึ้นตามภูมิหลังและแนวความคิดที่คุ้นเคย

OOP และ FP ดูข้อมูลและการดำเนินงานจากสองมุมมองที่แตกต่างกันและให้การแลกเปลี่ยนที่แตกต่างกันเนื่องจาก Robert Harvey ได้ชี้ให้เห็นแล้ว

สิ่งสำคัญอย่างหนึ่งที่พวกเขาต่างกันคือวิธีที่พวกเขาอนุญาตให้ขยายซอฟต์แวร์ของคุณ

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

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

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

วิธีการขยายที่แตกต่างกันนี้เป็นหนึ่งในสาเหตุที่ OOP เหมาะสมกว่าสำหรับปัญหาบางอย่างที่ชุดการดำเนินการแตกต่างกันน้อยกว่าชุดของชนิดข้อมูลที่การดำเนินการเหล่านี้ทำงาน ตัวอย่างทั่วไปเป็น GUIs: คุณมีชุดถาวรของการดำเนินงานที่วิดเจ็ตทั้งหมดจะต้องดำเนินการ ( paint, resize, moveและอื่น ๆ ) และคอลเลกชันของเครื่องมือที่คุณต้องการที่จะขยาย

ดังนั้นตามมิตินี้ OOP และ FP เป็นเพียงสองวิธีในการจัดระเบียบโค้ดของคุณ ดูSICPโดยเฉพาะในมาตรา 2.4.3 ตาราง 2.22 และวรรคผ่านข้อความ

การสรุป: ใน OOP คุณใช้ข้อมูลเพื่อจัดระเบียบการปฏิบัติงานใน FP คุณใช้การดำเนินการเพื่อจัดระเบียบข้อมูล แต่ละวิธีมีความแข็งแกร่งหรือปรับตัวลดลงตามบริบท โดยทั่วไปแล้วทั้งสองไม่มีช่องว่างการเป็นตัวแทนที่สูงขึ้นระหว่างปัญหาและการแก้ปัญหา

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

วิธีที่คุณทำงานกับประเภทเหล่านี้ใน Haskell มักจะไม่ค่อยแตกต่างจากวิธี OO ใน Haskell ฉันพูด

  null xs
  length xs

และใน Java คุณพูด

  xs.isEmpty
  xs.length

มะเขือเทศมะเขือเทศ ฟังก์ชั่น Haskell ไม่ได้เชื่อมโยงกับวัตถุ แต่มีความสัมพันธ์อย่างใกล้ชิดกับประเภทของมัน “ แต่ถ้าคุณพูดว่า“ ใน Java มันกำลังเรียกใช้วิธีการยาวซึ่งเหมาะสมกับคลาสจริงของวัตถุนั้น” เซอร์ไพร์ส - Haskell ก็มีหลายรูปแบบเช่นกันกับคลาสประเภท (และสิ่งอื่น ๆ )

ใน Haskell ถ้าฉันมีคือ - คอลเลกชันของจำนวนเต็ม - มันไม่สำคัญว่าคอลเลกชันนี้เป็นรายการหรือชุดหรืออาร์เรย์รหัสนี้

  fmap (* 2) is

จะส่งคืนคอลเล็กชันที่มีองค์ประกอบทั้งหมดเป็นสองเท่า ความแตกต่างหมายถึงฟังก์ชั่นแผนที่ที่เหมาะสมสำหรับประเภทที่เฉพาะเจาะจงจะถูกเรียก

อันที่จริงตัวอย่างเหล่านี้ไม่ใช่ประเภทที่ซับซ้อนจริง ๆ แต่ใช้ในปัญหาที่ยากกว่า แนวคิดที่ว่าภาษาที่ใช้งานได้นั้นไม่อนุญาตให้คุณจำลองวัตถุที่ซับซ้อนและเชื่อมโยงการทำงานเฉพาะกับพวกเขานั้นผิด

มีมีความแตกต่างที่สำคัญและมีความสำคัญระหว่างการทำงานและ OO สไตล์ แต่ฉันอย่าคิดว่าคำตอบนี้จะจัดการกับพวกเขา คุณถามว่าภาษาที่ใช้งานป้องกัน (หรือขัดขวาง) การสร้างแบบจำลองปัญหาและงานที่ใช้งานง่าย คำตอบคือไม่

FP มุ่งมั่นอย่างแท้จริงในการลดช่องว่างในการนำเสนอ:

สิ่งที่คุณจะเห็นจำนวนมากในภาษาการทำงานคือการปฏิบัติของการสร้างภาษาขึ้น (โดยใช้การออกแบบด้านล่างขึ้น) ลงนั้นฝังตัวเฉพาะโดเมนภาษา (EDSL) สิ่งนี้ช่วยให้คุณพัฒนาวิธีการแสดงความกังวลทางธุรกิจของคุณในลักษณะที่เป็นธรรมชาติสำหรับโดเมนของคุณในภาษาการเขียนโปรแกรม Haskell และ Lisp ต่างก็ภูมิใจในสิ่งนี้

ส่วนที่ (ถ้าไม่ทั้งหมด) ของสิ่งที่ช่วยให้ความสามารถนี้มีความยืดหยุ่นมากขึ้นและความหมายในภาษาพื้นฐาน (s) ตัวเอง; ด้วยฟังก์ชั่นชั้นหนึ่ง, ฟังก์ชั่นที่มีลำดับสูงกว่า, องค์ประกอบของฟังก์ชั่นและในบางภาษา, ชนิดข้อมูลเกี่ยวกับพีชคณิต (สหภาพจำแนกจำแนกทาง AKA) และความสามารถในการกำหนดตัวดำเนินการ * มีความยืดหยุ่นมากขึ้นสำหรับวิธีการแสดงสิ่งต่างๆ หมายความว่าคุณอาจพบวิธีที่เป็นธรรมชาติในการแสดงสิ่งต่าง ๆ จากโดเมนปัญหาของคุณ (ควรพูดถึงบางสิ่งที่ภาษา OOP หลายภาษาได้นำคุณสมบัติเหล่านี้มาใช้ไม่นานมานี้หากไม่ได้เริ่มต้นด้วย)

_{* ใช่ในหลายภาษาของ OOP คุณสามารถแทนที่ผู้ให้บริการมาตรฐานได้ แต่ใน Haskell คุณสามารถกำหนดใหม่ได้!}

จากประสบการณ์ของฉันที่ทำงานกับภาษาที่ใช้งานได้ (ส่วนใหญ่เป็น F # และ Haskell, Clojure บางส่วนและ Lisp และ Erlang เล็กน้อย) ฉันมีเวลาทำแผนที่ได้ง่ายขึ้นในการแก้ปัญหาพื้นที่ในภาษามากกว่าที่ฉันทำกับ OOP - โดยเฉพาะอย่างยิ่งกับชนิดข้อมูลเชิงพีชคณิต ซึ่งฉันพบว่ามีความยืดหยุ่นมากกว่าชั้นเรียน สิ่งที่ทำให้ฉันมีอาการวนเมื่อเริ่มต้นด้วย FP โดยเฉพาะกับ Haskell คือฉันต้องคิด / ทำงานในระดับที่สูงขึ้นเล็กน้อยกว่าที่ฉันเคยเป็นภาษาบังคับหรือ OOP; คุณอาจจะเจอปัญหานี้เช่นกัน

ดังที่ Niklaus Wirth กล่าวไว้ว่า "อัลกอริทึม + โครงสร้างข้อมูล = โปรแกรม" ฟังก์ชั่นการเขียนโปรแกรมเป็นเรื่องเกี่ยวกับวิธีการจัดระเบียบอัลกอริทึมและมันไม่ได้บอกอะไรมากมายเกี่ยวกับวิธีการจัดระเบียบโครงสร้างข้อมูล แท้จริงแล้วมีภาษา FP อยู่ทั้งที่มีตัวแปรที่ไม่แน่นอน (Lisp) และไม่เปลี่ยนรูป (Haskell, Erlang) หากคุณต้องการเปรียบเทียบและเปรียบเทียบความแตกต่างของ FP กับบางอย่างคุณควรเลือกการเขียนโปรแกรมที่จำเป็น (C, Java) และการประกาศ (Prolog)

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

ดังนั้นฉันไม่เห็นว่าทำไม FP จึงควรทำให้การแก้ปัญหาโดยทั่วไปเข้าใจยากขึ้นและฉันไม่คิดว่าจะทำเช่นนั้น อย่างไรก็ตามโปรดจำไว้ว่าโปรแกรมเมอร์ที่มีความจำเป็นที่มีประสบการณ์ต้องพบโปรแกรมการทำงานที่เข้าใจยากกว่าโปรแกรมที่จำเป็นและในทางกลับกัน สิ่งนี้คล้ายกับ Windows - Linux dichotomy เมื่อผู้ที่ลงทุน 10 ปีเพื่อให้คุ้นเคยกับสภาพแวดล้อมของ Windows พบว่า Linux ใช้งานได้ยากหลังจากใช้งานมาหนึ่งเดือน ดังนั้น 'ช่องว่างแทน' ที่คุณกำลังพูดถึงเป็นเรื่องส่วนตัวมาก