สำหรับปัญหาทั่วไปคือการเขียนโปรแกรมใช้งานไม่เหมาะหรือไม่ [ปิด]

22

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้

ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้

ปิดให้บริการใน5 ปีที่ผ่านมา

ฟังก์ชั่นการเขียนโปรแกรมเป็นกระบวนทัศน์ที่เปิดเผย หนึ่งในพลังของ FP คือการหลีกเลี่ยงผลข้างเคียง ได้มีการกล่าวว่าสำหรับปัญหาบางอย่าง FP นั้นไม่เหมาะสม

สำหรับปัญหาทั่วไปที่พบว่าการเขียนโปรแกรมใช้งานไม่ได้เหมาะสมหรือไม่

functional-programming paradigms

— โจนัส
แหล่งที่มา

ต๊าย! ครู่หนึ่งฉันคิดว่าคุณพูดว่า "เป็นกระบวนทัศน์ที่มีข้อบกพร่อง " จากนั้นฉันกลับมาและตรวจสอบ

— ทำเครื่องหมาย C

1

ฉันคิดว่ามันแม่นยำมากกว่าที่จะบอกว่าผลข้างเคียงนั้นถูกแยกออก (ใน Haskell ต่อไป) มากกว่าที่หลีกเลี่ยง Monads อนุญาตให้มีการเปลี่ยนแปลงสถานะและอีกชื่อหนึ่งคือ "รัฐ"

— Larry Coleman

ดังที่ Larry Coleman อธิบายไว้มันไม่เป็นความจริงที่การเขียนโปรแกรมการทำงานหลีกเลี่ยงผลข้างเคียง แต่เป็นการกีดกันการใช้งานของพวกเขาและในบางภาษามันแยกพวกเขาออกอย่างชัดเจน อ่านเช่นหมวดที่ 7 ของresearch.microsoft.com/en-us/um/people/simonpj/papers/…

— Giorgio

17

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

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

(ในฐานะที่เป็นบันทึกด้านข้าง, ปัญหาบางอย่างในเกมเหมาะมากสำหรับการเขียนโปรแกรมการทำงานเช่น AI ภาษาที่ใช้งานได้ / คำสั่งแบบผสมจะเหมาะอย่างยิ่งสำหรับกรณีเหล่านั้น)

— Matt Olenik
แหล่งที่มา

9

บทความThe Next Mainstream Programming Languages: มุมมองของผู้พัฒนาเกมระบุว่าสำหรับการพัฒนาเกมโดยเฉพาะซึ่งพฤติกรรมการทำงานล้วน แต่เป็นค่าเริ่มต้นและการเปลี่ยนแปลงสถานะจะถูกติดตามผ่านประเภทต่างๆเพื่อหลีกเลี่ยงข้อบกพร่อง ดังนั้นไม่ใช่ทุกคนที่เชื่อว่ากระบวนทัศน์การทำงานนั้นไม่เหมาะสมสำหรับการเขียนโปรแกรมเกม

— sepp2k

1

@ sepp2k ขอบคุณสำหรับลิงค์ ฉันดีใจที่ได้เห็นมุมมองที่ถกเถียงกันจากคนที่ทำเกมจริง

— Matt Olenik

3

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

— Matt Olenik

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

— sepp2k

@ sepp2k ใช่ฉันเห็นสิ่งที่คุณหมายถึง

— Matt Olenik

17

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

— AShelly
แหล่งที่มา

3

ถ้าคุณแค่หมายถึงส่วนต่อประสานฮาร์ดแวร์ฉันสงสัยว่าสิ่งอื่นนอกเหนือจาก C / C ++ เป็นตัวเลือกที่ดี อย่างไรก็ตามในบางครั้งการใช้เลเยอร์ที่ด้านบนของภาษาอย่าง Erlang โดยเฉพาะในระบบโทรคมนาคม Erlang เป็นภาษาที่ใช้งานได้ออกแบบมาสำหรับระบบเรียลไทม์แบบฝังที่สำคัญและทนต่อความผิดพลาด

— Jonas

@Jonas: Erlang อาจลดการกลายพันธุ์ให้น้อยที่สุด แต่ขึ้นอยู่กับ IO อย่างมากในการส่งข้อความซึ่งแน่นอนว่าเป็นผลข้างเคียง

— Jon Harrop

11

ฉันขอยืนยันว่าการเขียนโปรแกรม GUI ไม่เหมาะสำหรับการเขียนโปรแกรมการทำงาน โดยทั่วไปแล้ว GUIs จะมีสถานะเป็นรัฐมากและง่ายกว่ามากในการสร้างแบบจำลอง / จัดการโดยใช้สถานะแทนที่จะใช้ผลข้างเคียงฟรี แน่นอนว่าเป็นไปได้ที่จะใช้ภาษาการเขียนโปรแกรมที่ใช้งานได้กับ GUI ... แต่อาจไม่ใช่ความคิดที่ดี

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

— mipadi
แหล่งที่มา

-1: คุณกำลังพูดถึงความบริสุทธิ์และการเพิกเฉยต่อการใช้งานฟังก์ชั่นชั้นหนึ่งเช่นการโทรกลับในรหัส GUI นั้นง่ายกว่ามากเมื่อใช้ภาษา FP ที่ไม่บริสุทธิ์มากกว่าภาษา OOP

— Jon Harrop

4

@Jon Harrop: ฟังก์ชั่นชั้นหนึ่งไม่เหมือนกันกับภาษาโปรแกรมที่ใช้งานได้ ฉันยังคงยืนยันว่าสไตล์ FP นั้นไม่เหมาะสำหรับ GUI

— mipadi

1

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

— Jon Harrop

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

— mipadi

... ฉันไม่พบว่ากระบวนทัศน์นี้สามารถแก้ไขการเขียนโปรแกรม GUI โดยเฉพาะ - ภาษาเชิงวัตถุเป็นแบบที่ดีกว่าสำหรับ GUI โดยทั่วไปแล้วการพูด

— mipadi

5

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

— Branimir
แหล่งที่มา

2

และแอพพลิเคชั่น data / view อื่น ๆ จริงๆ เกมส่วนใหญ่เกี่ยวกับสถานะและการเปลี่ยนแปลงดังนั้นจึงไม่สามารถแปลได้ดีในรูปแบบการใช้งาน

— Jon Purdy

18

จริงๆ? ฉันคิดเสมอว่า FP จะดีสำหรับสิ่งนี้โดยเฉพาะ 99% ของสิ่งที่แอพเหล่านั้นเลือกรวบรวมและฉายข้อมูลหรือไม่ ที่เป็นพื้นfilter, และreduce mapโยนในบางsort, ,partition groupByท้ายที่สุดแล้วภาษาการเขียนโปรแกรมที่ใช้กันอย่างแพร่หลายสำหรับการเขียนโปรแกรมดังกล่าวคือ Excel ซึ่งเป็นภาษาที่ใช้งานได้

— Jörg W Mittag

3

แอพพลิเคชั่นและแอพพลิเคชั่นทางธุรกิจที่ขับเคลื่อนด้วยข้อมูลด้วยการใช้งานข้อมูลที่เรียบง่ายดูเหมือนว่าเหมาะอย่างยิ่งสำหรับ FP และฉันได้ยินมาว่า FP นั้นเป็นที่นิยมสำหรับสิ่งต่าง ๆ เช่นดูโปรแกรมเมอร์การทำงานของ Adventures Fa บน Wall Street

— Jonas

1

-1: คุณได้แสดงรายการแอปพลิเคชันที่ FP ยอดเยี่ยมที่

— Jon Harrop

2

คุณไม่สามารถยกเลิกชุดปัญหาใด ๆ ได้อย่างง่ายดายเพราะไม่เหมาะกับการเขียนโปรแกรมใช้งานต่อเนื่อง

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

ตัวอย่างหนึ่งคือ Erlang ที่กล่าวถึงแล้วสำหรับระบบฝังตัวตามเวลาจริง

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

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

ไม่จำเป็นต้องมีผลข้างเคียงโดยพลการเช่นตัวแปรส่วนกลางเลย

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

แม้ว่าการเขียนโปรแกรม C เป็นความคิดที่ดีเสมอที่จะลดผลข้างเคียงโดยพลการเช่นตัวแปรทั่วโลกให้มากที่สุด

— Peer Stritzinger
แหล่งที่มา

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

— Jonas

หากคุณมีกระบวนการ / เธรดนามธรรม (เช่นใน Erlang) คุณสามารถผ่านสถานะของคุณในกระบวนการ

— Peer Stritzinger

3

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

— Peer Stritzinger

1

@ Jonas: ใน Haskell คุณอาจใช้ IO monad, State monad หรือชุดค่าผสม

— Larry Coleman

1

@Jonas: ขึ้นอยู่กับคำจำกัดความที่มีประโยชน์ของคุณ ตัวอย่าง wikibook ใช้ wxHaskell ในขณะที่ Real World Haskell ใช้ gtk2hs ฉันไม่ได้ลองเพราะแอพ Haskell เป็นแบบบรรทัดคำสั่ง

— Larry Coleman