สามารถใช้การเขียนโปรแกรมเชิงฟังก์ชั่นเพื่อพัฒนาแอปพลิเคชันระดับองค์กรได้หรือไม่

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

หากบางสิ่งไม่สามารถเปลี่ยนแปลงได้สิ่งที่เป็นวัตถุทั่วไปเช่นพนักงานหรือบุคคลที่แสดงใน FP

สามารถใช้ FP เพื่อสร้างแอปพลิเคชันระดับองค์กรที่มีคุณสมบัติครบถ้วนได้หรือไม่

คำถามไม่สามารถใช้ FP ในองค์กรได้หรือไม่ แต่เราควรใช้ FP ใน Enteprise หรือไม่

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

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

ทีนี้คุณอาจถามว่า "ทำไมไม่ใช้มากกว่านี้" ส่วนใหญ่เป็นเพราะภาษา Imperative / OO อื่น ๆ เป็นเรื่องธรรมดามากขึ้นและ บริษัท ปฏิเสธที่จะเปลี่ยนเป็นภาษา "แปลกใหม่" มากขึ้นเพราะพวกเขาจะใช้ภาษาจาวาหรือ C ++

ฉันเริ่มเรียนรู้เกี่ยวกับภาษา FP สองสามปีที่ผ่านมา (Haskell, Scala, Scheme) และถึงแม้ว่าฉันจะไม่เชี่ยวชาญ แต่ฉันพบว่าพวกเขาสามารถทำให้ฉันมีประสิทธิผลอย่างมากสำหรับงานบางอย่างมากกว่า C ++ หรือ Java .

IMO จุดแข็งของภาษา FP คือ:

• พวกเขามีแนวโน้มที่จะรัดกุมมาก แต่พวกเขายังคงความหมายที่ชัดเจน
• คุณสามารถใช้สไตล์การประกาศและไม่ต้องคิดมากเกี่ยวกับรายละเอียดการใช้งานมากเกินไป
• ระบบประเภทที่หลากหลายเช่น Haskell สามารถตรวจจับข้อผิดพลาดเชิงตรรกะได้เร็วมาก (ในเวลารวบรวม) เท่าที่ฉันรู้ (ไม่มากจริงๆ) SML และ Ocaml มีข้อได้เปรียบที่คล้ายกัน

ถึงตอนนี้ฉันได้พบว่าการสลับไปยังกระบวนทัศน์ของ FP ค่อนข้างน่าตื่นเต้นและไม่ยากเกินไปเมื่อคุณใช้เวลากับมันมากพอ (แต่ฉันใช้เวลาในการเรียนรู้ C หรือ C ++ เป็นเวลานานเท่าใดค่อนข้างมาก!)

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

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

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

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

ฉันไม่คิดว่ามันเป็นความคิดที่ดีที่สุด แต่ขึ้นอยู่กับลักษณะของแอปพลิเคชันเฉพาะ

ฉันเชื่อในปรัชญาของ Eric Evans มากมายดังที่อธิบายไว้ในหนังสือของเขาที่ชื่อว่าDomain-Driven Designซึ่งคุณควรสร้างรูปแบบโดเมนที่แสดงถึงปัญหาที่สามารถช่วยคุณแก้ปัญหาได้ อีแวนส์แนะนำให้หาภาษาโปรแกรมที่มีปัญหาเฉพาะหน้าเช่นเขาระบุว่า Fortran เป็นวิธีการแก้ปัญหาในลักษณะทางคณิตศาสตร์ หรือแม้แต่การสร้างภาษาเฉพาะโดเมนเฉพาะสำหรับปัญหาที่อยู่ในมือ

เมื่อคุณประสบความสำเร็จในการสร้างแบบจำลองโดเมนที่ดีคุณจะพบว่ารหัสงานนำเสนอกลายเป็นเปลือกบาง ๆ ที่ด้านบนของเลเยอร์โดเมน

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

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

แต่โดยทั่วไปฉันคิดว่ากระบวนทัศน์เชิงวัตถุช่วยให้สามารถสร้างแบบจำลองโดเมนที่มีประโยชน์มากขึ้นสำหรับแอปพลิเคชันองค์กรส่วนใหญ่

แก้ไข

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

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

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

โปรดทราบว่าเทคนิคนี้สามารถใช้งานได้โดยใช้ภาษาที่จำเป็น!

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

ใช่ FP สามารถใช้ในแอปพลิเคชันองค์กร Clojure เป็นหนึ่งในตัวอย่างของภาษา FP ที่ประสบความสำเร็จในองค์กร: http://cognitect.com/clojure#successstories

การเป็นตัวแทนของรัฐอาจเป็นสิ่งที่ท้าทายใน FP และการเปลี่ยนกระบวนทัศน์ให้เหมาะสมกับ FP อาจเป็นความคิดที่บิดเบือน ภาษา FP บางภาษาไม่อนุญาตให้มีผลกระทบข้างเคียงอย่างสมบูรณ์ Clojure อนุญาตให้ทั้ง แต่กีดกันหรือแยกกระบวนทัศน์เหล่านั้น

ในระยะสั้นการเป็นตัวแทนรัฐอาจคล้ายกับ OO มาก มันเป็นการปรับเปลี่ยนสถานะที่แตกต่างกันมาก ตัวอย่างเช่นในสถานะ FP อาจมีการแสดงรายการและแผนที่ รายชื่อพนักงานอาจมีลักษณะดังนี้:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

มีสองวิธีที่ฉันรู้ในการจัดการการปรับเปลี่ยนสถานะใน FP หนึ่งคือสิ่งที่ต้องการเขียนโปรแกรมปฏิกิริยาการทำงาน ในกระบวนทัศน์นี้สถานะทั้งหมดจะถูกจัดการในระดับสูงสุดเท่านั้น ... เช่นมุมมอง HTML ของแอปพลิเคชันของคุณมีสถานะในมุมมอง (เช่นชื่อบุคคลที่อยู่ ฯลฯ ) ตอนนี้เมื่อคุณคลิก "update name" ฟังก์ชั่นที่เรียกว่าจัดการทุกอย่างเกี่ยวกับการปรับปรุงชื่อยกเว้นการเปลี่ยนชื่อจริง นี่อาจฟังดูแปลก ... แต่อดทนกับฉัน ชื่อที่ถูกเปลี่ยนจะถูกส่งคืนโดยฟังก์ชันและมุมมอง (หรือที่เก็บข้อมูลถาวรเป็นต้น) จะแสดงชื่อใหม่ หรือมิฉะนั้นโครงสร้างใหม่ทั้งหมดที่มีชื่อที่อัปเดตจะถูกส่งคืน ดังนั้นฟังก์ชั่นทำอะไร มันตรวจสอบชื่อและส่งกลับชื่อใหม่ถ้ามันถูกต้องข้อผิดพลาดหากไม่ได้ และอาจเป็นมุมมองใหม่หรือลิงก์การนำทางเพื่อติดตาม สำหรับบางสิ่งที่ซับซ้อนกว่าการเปลี่ยนชื่ออาจทำได้มากกว่านี้มาก

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

ด้วยกระบวนทัศน์นี้คอนเทนเนอร์หรือเฟรมเวิร์กจำเป็นต้องจัดการกับการอัพเดตของจอแสดงผลฐานข้อมูลหรืออะไรก็ตามที่ต้องการการอัพเดตจากสถานะใหม่ ดังนั้นคุณสามารถจินตนาการถึงกรอบที่ดึงแอปพลิเคชันบนหน้าจอ เมื่อผู้ใช้คลิกที่ฟังก์ชันบางอย่างจะถูกเรียกใช้และสถานะใหม่จะถูกส่งกลับ เฟรมเวิร์กจะอัพเดตหน้าจอโดยการวาดใหม่ทุกอย่างหรือวาดใหม่อย่างชาญฉลาดในส่วนของจอแสดงผล ดูhttp://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure ใช้กระบวนทัศน์ที่สองที่ฉันได้เจอและนั่นคือการแยกการเปลี่ยนแปลงสถานะ แต่ไม่จำเป็นต้อง จำกัด พวกเขาในระดับสูงสุด ด้วย Clojure สถานะที่ไม่แน่นอนทั้งหมดจะต้อง "หยุด" (ยกเว้นว่าคุณกำลังใช้วัตถุ Java สำหรับสถานะ) โดยอะตอมเอเจนต์หรือการอ้างอิง วิธีการทำงานนี้คือวัตถุที่ถือหรือชี้ไปที่หรืออ้างอิง (แต่คุณต้องการเรียกมัน) โดย atom / agent / ref นั้นไม่เปลี่ยนรูป แต่ atom / agent / ref สามารถเปลี่ยนให้ชี้ไปที่วัตถุใหม่ ในกรณีนี้คุณใช้วิธีพิเศษใน atom / agent / ref ที่พูดว่า "update object ที่นี่โดยทำเช่นนั้นและทำการมอบหมาย atom / agent / ref ให้กับวัตถุใหม่"

ทำไมสิ่งนี้จึงเป็นประโยชน์คุณอาจถาม? เพราะวัตถุที่ไม่เปลี่ยนรูปอ้างอิงโดยการก่อสร้าง Clojure เหล่านี้อาจถูกส่งผ่านไปยังฟังก์ชั่นที่ทำอะไรบางอย่างและในขณะที่ฟังก์ชั่นนั้นกำลังเรียกใช้การอ้างอิงไปยังวัตถุที่มีการรับประกันว่าจะไม่เปลี่ยนแปลง นั่นคืออะตอม / เอเจนต์ / ref จะไม่ถูกส่งผ่านไปยังฟังก์ชัน แต่วัตถุที่ไม่เปลี่ยนรูปซึ่งชี้โดยพวกมันจะถูกส่งผ่าน อะตอมตัวแทนและผู้อ้างอิงมีคุณสมบัติพิเศษที่จัดการการปรับปรุงและการทำงานพร้อมกันในรูปแบบที่ปลอดภัยและเป็นส่วนหนึ่งของภาษา ดูhttp://clojure.org/state

ฉันหวังว่านี่จะช่วยได้. ฉันขอแนะนำให้อ่านเพิ่มเติมเกี่ยวกับรัฐ Clojure และ FRP เพื่อรับความเข้าใจที่ดีขึ้นสำหรับวิธีการที่พนักงานและบุคคลสามารถแสดงใน FP แม้ว่าการแสดงจริงจะคล้ายกับการเขียนโปรแกรมเชิงวัตถุ ... มันเป็นความไม่แน่นอนที่แตกต่างกันจริงๆ