เหตุใดการเขียนโปรแกรมเชิงฟังก์ชันจึงไม่เป็นที่นิยมในอุตสาหกรรม มันจับในตอนนี้หรือไม่ [ปิด]

61

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

อย่างไรก็ตามเมื่อมองหางานมันเป็นเรื่องยากมากที่จะเห็นงานที่ต้องใช้ความรู้เกี่ยวกับภาษาโปรแกรมการทำงาน

เหตุใดภาษาการเขียนโปรแกรมที่ใช้งานไม่ได้ใช้ในอุตสาหกรรมมากกว่า มีข่าวมากมายเกี่ยวกับภาษาการเขียนโปรแกรมเพื่อการใช้งานในปัจจุบันดังนั้นฉันจึงสงสัยว่าการเขียนโปรแกรมเชิงฟังก์ชั่นกำลังเป็นที่สนใจในอุตสาหกรรมนี้หรือไม่?

functional-programming 
— โจนัส
แหล่งที่มา
3
ฉันไม่เห็นด้วยกับหลักฐานของคำถามของคุณ คุณสมบัติภาษาได้รับแรงบันดาลใจจาก "ภาษาที่ใช้งานได้" กำลังถูกเพิ่มลงในภาษาเช่น Java และ JavaScript อันที่จริง JavaScript เป็นภาษาที่ใช้งานได้ (ในบางวิธี) แม้ว่าผู้คนจำนวนมากจะไม่เข้าใจจนกระทั่งเมื่อไม่นานมานี้
— MatrixFrog
1
@ MatrixFrog: ใคร ๆ ก็ถามว่า "ทำไมใช้งานได้เพียงครึ่งทางโดยเพิ่มแนวคิดการทำงานบางอย่างให้กับภาษาที่ไม่ใช้งานได้แทนที่จะใช้ภาษา FP เต็มรูปแบบ? หลังจากที่กระบวนทัศน์รอบด้านมานานหลายปีและเป็นผู้ใหญ่มาก"
— Giorgio
โลกไม่ได้เปลี่ยนไปใช้ทางเลือกที่เหนือกว่า (และบริสุทธิ์ FP เป็นทางเลือกที่ดีกว่า) ด้วยเหตุผลที่แตกต่างกันเช่นความเข้ากันได้แบบย้อนกลับความเฉื่อยเป็นต้นพิจารณารูปแบบแป้นพิมพ์ DVORAK: มันมีประสิทธิภาพมากขึ้นสำหรับการพิมพ์ด้วยระบบสัมผัส พร้อมกับทางลัดที่เป็นมิตรกับ qwerty
— KolA

คำตอบ:

38

ฉันจะบอกว่าหนึ่งในเหตุผลที่การเขียนโปรแกรมฟังก์ชั่นไม่แพร่หลายมากขึ้นคือการขาดฐานความรู้ ประสบการณ์ของฉันคือ บริษัท มีความเสี่ยงมากในแง่ของการใช้เทคโนโลยีที่ไม่ใช่กระแสหลักและค่อนข้างจะลงทุนในกรอบความพยายามและความจริง (Java, c ++, c #) เฉพาะเมื่อมีความต้องการทางธุรกิจ (เช่นใน Ericsson) ที่มีการพิจารณากระบวนทัศน์ใหม่ แต่ในกรณีของ Ericsson ฉันได้ยินมาว่าฝ่ายบริหารเรียกร้องให้ใช้ c ++ และ Joe Armstrong ถูกบังคับให้เรียกรหัส erlang ใน c ++ !! นี่ควรจะแสดงให้เห็นว่า บริษัท ที่ไม่เต็มใจจะนำเทคโนโลยีใหม่มาใช้!

— ennuikiller
แหล่งที่มา
9
การเขียนโปรแกรมการทำงานในทางใดทาง 'ใหม่'?
— Evan Plaice
7
ฉันคิดว่าเขาหมายถึง 'ไม่ได้ใช้' แทน 'ใหม่'
— Vinko Vrsalovic
9
ดังนั้นมันไม่ได้ใช้ ... เพราะมันไม่ได้ใช้? ฮึ่ม
— Alex Baranosky
21
@Alex - อย่างแน่นอน แย่ใช่มั้ย
— KeithS
5
@ Stargazer712: เหตุผลเหล่านั้นคืออะไร? ฉันรู้ว่านักพัฒนาจำนวนมากที่ไม่รู้จักการเขียนโปรแกรมที่ใช้งานได้ดังนั้นความไม่รู้จึงเหมาะสมสำหรับฉัน การเขียนโปรแกรมฟังก์ชั่นมีความล้มเหลวอย่างมากในอดีตที่ไล่ล่าอุตสาหกรรมที่อยู่ห่างจากที่ฉันไม่รู้
— Sean McMillan
67

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

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

เนื่องจากการเขียนโปรแกรมที่ใช้งานได้เป็นเพียงลูกศรเดียวที่มีอยู่ในตัวสั่นของคุณไม่ใช่ลูกศรเดียวอย่างที่ OOP ไม่ใช่คนเดียว

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

— Mike Dunlavey
แหล่งที่มา
1
นี่เป็นความคิดเห็นที่ดีจริงๆ +1 เพื่อลูกศรในสั่นของคุณและช่วงของการแก้ปัญหาด้วยการแลกเปลี่ยน
— user21007
2
+1 สำหรับ QC MSc ที่จะได้รับมากมีประโยชน์กับวิชาเฉพาะครอบคลุมการทดสอบการตรวจสอบรหัสซับซ้อนรหัสและที่คล้ายกัน ความสามารถในการตรวจสอบโดยอัตโนมัติว่าโปรแกรมทำสิ่งที่ควรหลังจากแพทช์สุดท้ายมีค่าจำนวน "มันควรจะทำงานตอนนี้" ซึ่งพูดพล่อยๆด้วยมือ
— l0b0
5
@ l0b0: ขอบคุณแม้ว่าจริง ๆ แล้วฉันก็คิดถึงการควบคุมคุณภาพของสิ่งที่สอนและวิธีการ เนื่องจากอาจารย์สอน CS เพียงแค่สอนสิ่งที่พวกเขาพบว่าน่าสนใจที่สุด เปรียบเทียบกับวิศวกรรมที่มีการเชื่อมโยงกับอุตสาหกรรมหรือยาที่ความเกี่ยวข้องในโลกแห่งความจริงนั้นสูงมาก IME, CS profs คิดว่าโลกแห่งความจริงจะทำการสอนสิ่งที่สำคัญในโลกแห่งความจริง แต่นักเรียนไม่ได้กระตือรือร้นที่จะเรียนรู้ - แต่พวกเขากระตือรือร้นที่จะทำให้สิ่งที่ศาสตราจารย์ตื่นเต้นที่สุดมาทำให้เป็นจริง
— Mike Dunlavey
@ ไมค์: แค่เกี่ยวกับภาษาที่ทันสมัย? คุณรวม C ++ และ Java หรือไม่
— วินไคลน์
+1 ไม่สามารถพูดได้ดีกว่านี้
— riwalk
25

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

— Fishtoaster
แหล่งที่มา
48
ฉันไม่เห็นด้วย. ภาษาโปรแกรมที่ใช้งานได้พยายามลดการใช้สถานะให้น้อยที่สุดและทำให้ซับซ้อนน้อยลง โปรแกรมที่ตั้งโปรแกรมในภาษาที่ใช้งานได้นั้นยังง่ายต่อการทดสอบและสร้างซ้ำ
— Jonas
7
@ Jonas: โปรแกรมเมอร์จำนวนมากพบว่ามันยากมากที่จะเขียนโปรแกรมโดยใช้เกือบจะไม่มีรัฐเลย (รวมถึงตัวเองด้วย) จากมุมมองนั้นจริง ๆ แล้วมันซับซ้อนมากขึ้น (โปรดทราบว่าฉันไม่ได้อภิปรายประโยชน์ของการเขียนโปรแกรมฟังก์ชั่นโดยวิธีการใด ๆ !)
— ShdNx
3
@ShdNx: ใช่ฉันรู้ แม้ฉันคิดว่าการเขียนโปรแกรมเชิงฟังก์ชั่นเป็นเรื่องยากเมื่อฉันเรียนรู้ครั้งแรกในมหาวิทยาลัย แต่หลังจากนั้นไม่นานฉันก็เริ่มชอบการเขียนโปรแกรมที่จำเป็นและ OOP ที่เฉพาะเจาะจงมากขึ้น ที่การเขียนโปรแกรมการทำงานในมหาวิทยาลัยของฉันได้รับการสอนก่อนการเขียนโปรแกรมที่จำเป็นและนักเรียนที่ไม่ได้ทำโปรแกรมใด ๆ ก่อนที่มหาวิทยาลัยจะคิดว่าการเขียนโปรแกรมที่จำเป็นนั้นยากมากในตอนเริ่มต้นและการเขียนโปรแกรมเชิงปฏิบัติการนั้นใกล้เคียงกับคณิตศาสตร์มากขึ้น
— Jonas
16
มีความแตกต่างระหว่างความยากและความซับซ้อน OOP นั้นยากกว่าการเขียนโปรแกรมที่มีโครงสร้างเนื่องจากเป็นการเพิ่มแนวคิดเพิ่มเติม สำหรับโค้ดที่มีจำนวนมากพอจะช่วยลดความซับซ้อนโดยจัดเตรียมโครงสร้างให้กับโค้ด FP คือสิ่งเดียวกัน: ถ้าคุณเขียนเพียงสองบรรทัดดูเหมือนว่า overkill แต่ถ้ารหัสของคุณมีขนาดใหญ่พอแล้วโครงสร้างของโค้ดเนื่องจากหน่วยย่อยไร้สัญชาติจะช่วยเพิ่มความสามารถในการปรับขยายและลดความซับซ้อนของรหัส
— Muhammad Alkarouri
6
หนึ่งในจุดเน้นหลักของการเขียนโปรแกรมฟังก์ชั่นคือการจัดองค์ประกอบ หากนั่นไม่ใช่เครื่องมือสำหรับจัดการความซับซ้อนฉันไม่รู้ว่ามันคืออะไร
— dan_waterworth
23

ฟังก์ชั่นการเขียนโปรแกรมนั้นเริ่มที่จะจับได้แน่นอน - ช้า แต่แน่นอน

ตัวอย่างเช่นการเริ่มต้นที่ฉันกำลังสร้างใช้ภาษาที่ใช้งานได้ (Clojure) เป็นภาษาการพัฒนาหลักด้วยเหตุผลดังต่อไปนี้:

  • ความสามารถในการผลิต - การเรียนรู้ FP นั้นยาก แต่เมื่อคุณได้รับมันแล้วก็ยากที่จะเอาชนะได้ในแง่ของพลังและความหมาย ฉันอาจจะเขียนเกี่ยวกับ 1 / 10th ของจำนวนบรรทัดเพื่อใช้งานส่วนใด ๆ ที่กำหนดเมื่อเทียบกับสิ่งที่ฉันต้องการใน C # หรือ Java

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

  • การทำงานพร้อมกัน - ภาษาที่ใช้งานเน้นการไม่เปลี่ยนรูปซึ่งมีประโยชน์มหาศาลสำหรับการใช้งานพร้อมกันมากกว่าที่จะต้องทำงานอย่างมีประสิทธิภาพในหลายคอร์ และชอบหรือไม่การทำงานกับหลายคอร์นั้นเป็นอนาคต ดูhttp://www.infoq.com/presentations/Value-Identity-State-Rich-Hickeyสำหรับคำอธิบายที่ยอดเยี่ยมว่าทำไมสิ่งนี้จึงสำคัญ

  • Composability / modularity - ภาษาที่ใช้งานได้ดูเหมือนจะยืมตัวเองเพื่อเชื่อมต่อส่วนประกอบเข้าด้วยกันได้ง่ายกว่าระบบ OO ที่ซับซ้อน ฉันยังไม่พบเหตุผลทั้งหมดสำหรับสิ่งนี้ แต่ส่วนหนึ่งเกิดจากความจริงที่ว่าคุณไม่มี "ความซับซ้อนโดยบังเอิญ" ทั้งหมดที่ OO โมเดลลากไปมากับพวกเขา การพูดคุยเกี่ยวกับRadical Simplicity โดย Stuart Hallowayสำรวจแนวคิดเหล่านี้ในเชิงลึกยิ่งขึ้น

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

— mikera
แหล่งที่มา
+1, ฉันสนใจมากที่จะทราบขั้นตอนการตัดสินใจของคุณว่าทำไมคุณถึงเลือก Clojure (ฉันไม่ได้เพื่อหรือต่อต้าน Clojure ฉันแค่สนใจ)
— dan_waterworth
4
"learning FP is hard": การเรียนรู้กระบวนทัศน์ใด ๆ นั้นยาก ฉันจำได้ว่าฉันใช้เวลากับรหัสคำสั่ง (Pascal) กี่ชั่วโมงก่อนที่ฉันจะมีประสบการณ์มากพอที่จะทำงานได้อย่างมีเหตุผล ฉันคิดว่า FP ไม่ค่อยมีใครรู้จักเพราะโปรแกรมเมอร์หลายคนเรียนรู้ภาษาที่จำเป็นก่อนและเมื่อพวกเขาเรียนรู้วิธีการเขียนโปรแกรมพวกเขาไม่มีเวลามองอย่างอื่น ฉันเป็นโปรแกรมเมอร์ C ++ เต็มเวลาและฉันกำลังเรียน Scala ในตอนเย็นหลังเลิกงาน ถ้าฉันมีครอบครัวคอยดูแลฉันก็สามารถลืมมันได้
— Giorgio
1
ฉันคิดว่า 3 รายการแรกเป็นกรณีที่ยอดเยี่ยม แต่ฉันไม่เห็นด้วยกับข้อที่ 4 OOP เป็นแบบแยกส่วนและ compositional สำหรับฉันนี้เป็นหนึ่งในจุดแข็งที่ยิ่งใหญ่ที่สุดของมัน นอกจากนี้ยังเป็นการดีในการซ่อนความซับซ้อนผ่านการห่อหุ้มและนามธรรม
— Despertar
1
@Giorgio เผง "การเรียนรู้ FP นั้นยากการเรียนรู้ OOP นั้นง่าย" นั้นไร้สาระเหมือน "การเรียนรู้ภาษาสเปนนั้นยาก แต่จีนก็ง่าย" ขึ้นอยู่กับว่าภาษาใดเป็นภาษาแรกของคุณ และฉันไม่ได้เลือกภาษาจีนเป็นอะนาล็อกตามอำเภอใจให้กับ OOP - เพราะสำนวน OO เป็นอักษรอียิปต์โบราณ: ง่ายต่อการเรียนรู้ทีละตัว แต่ยากที่จะจำได้ทั้งหมดและไม่สามารถเขียนได้ FP เป็นเหมือนภาษาที่มีตัวอักษรมากขึ้น: ตัวอักษรที่แยกต่างหากไม่มีประโยชน์ในการแยกออก แต่อนุญาตให้เขียนอะไรกับกฎชุดเล็ก ๆ ที่สมเหตุสมผล
— KolA
1
(ต่อ) ดังนั้นทำไมถึงไม่เป็นที่นิยม - ด้วย - ด้วยเหตุผลเดียวกัน อักษรอียิปต์โบราณมีมานานก่อนที่ตัวอักษรแรกถูกคิดค้นและครบกำหนด อาจต้องใช้คนรุ่นอื่นที่มีการเขียนและอ่านตัวอักษรฉันหมายถึง FP เป็นกระบวนทัศน์แรกของพวกเขา
— KolA
12

แอพที่ไม่มีนักฆ่า

เฮ้เจ้านี่ตรงนี้ดูสดชื่น (ขุดขุดขุด)

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

ต่อไปนี้เป็นมุมมองที่ไม่แม่นยำของฉันเกี่ยวกับสิ่งที่ซอกทำให้การยอมรับภาษาบางภาษาที่เรามีในวันนี้:

  • C: ทำงานได้ทุกที่ (นี่คือช่วงปลายยุค 70 และ 80)
  • C ++: กรอบงาน GUI (ช่วงต้น 90s)
  • Java: Applets และ servlets (ในช่วงปลายยุค 90)
  • วัตถุประสงค์ -C: แอป iOS (ก่อนหน้านั้นแอป OS X)
  • Ruby: Rails
  • C #: ASP.NET, WinForms
  • PHP: Wordpress ฯลฯ
  • Javascript: AJAX โดยเฉพาะอย่างยิ่งผ่านเฟรมเวิร์ก
  • lua: การเขียนสคริปต์เกมโดยเฉพาะ WoW

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

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

ดังนั้นภาษาที่ใช้งานได้ใด ๆ ที่ต้องการถอดออกจริงๆคือโพรง ในความเป็นจริงยังไม่มีภาษาที่ใช้งานได้ขนาดใหญ่ แต่มีภาษาที่เล็กกว่าทั้งหมดมากมาย:

  • Emacs Lisp: ใช้อย่างต่อเนื่องตั้งแต่ 80 ใน Emacs โดยนักพัฒนา ( แทบจะไม่เคยใช้ที่ใดเลย)
  • Erlang: ทุกที่ที่คุณต้องการตัวแทนพร้อมกันจำนวนมาก
  • โครงการ: การศึกษา
  • APL / J / K: การเงิน (มาเรียกฟังก์ชันเหล่านี้เพื่อประโยชน์ของการโต้แย้ง)
  • Common Lisp: "AI" - นี่คือสิ่งที่ผู้คนมักจะกล่าวว่ามันใช้สำหรับซึ่งเป็นคำอวยพรและคำสาป

ตอนนี้ภาษาหลักเดียวที่ฉันรู้สึกว่าฉันทิ้งไว้จากการสนทนานี้คือ Python Python ทำสิ่งที่น่าสนใจมาก มันประสบความสำเร็จโดยไม่ปรากฏว่าเป็นผู้ชนะในช่องที่สำคัญใด ๆ นี่อาจหมายความว่าฉันผิดพลาดในการดูความนิยมภาษาด้วยวิธีนี้ อาจหมายความว่าภาษาที่ดีพอจะกลายเป็นที่นิยมโดยไม่มีแอพนักฆ่าเพื่อผลักดันการยอมรับและยอมรับ แต่มันยากมากและอาจใช้เวลานาน (Perl มีเรื่องราวที่คล้ายกัน แต่มีไม่กี่ปีที่ผ่านมาและตอนนี้มีการดูดซับน้อยกว่า)

จากนี้ฉันสามารถพูดได้ว่าภาษาการทำงานที่ฉันคิดว่ากำลังเพิ่มขึ้น:

  • Clojure: การเขียนโปรแกรมเว็บโดยเฉพาะ ผ่าน Heroku
  • Scala: ยก (หรืออาจจะเล่นวันนี้) - JVM ไม่มี Java

หากคุณถามฉันว่าจะมองหาภาษาที่ใช้งานได้ต่อไปฉันจะบอกว่าเป็นภาษาที่ใช้งานได้กับการพัฒนาระบบคลาวด์แบบเบ็ดเสร็จ (a la Heroku หรือ GAE) หรือการพัฒนาแอพมือถือแบบเบ็ดเสร็จ

— Jesse Millikan
แหล่งที่มา
ฉันจะพิจารณา Perl เป็นภาษาหลักเช่นกัน มันเป็นภาษาที่เก่ากว่าที่ฉันจะบอกว่าใช้บ่อยที่สุดกับระบบที่เหมือน Unix แม้ว่า Python จะเป็นทางเลือกที่ทันสมัยกว่า มันยังคงเป็นภาษายอดนิยมที่ได้รับความสนใจและมีชุมชนขนาดใหญ่
— Despertar
1
@ เดสเปอร์ตาร์ - ฉันไม่ได้พยายามอย่างหนักโดยเฉพาะอย่างยิ่งที่จะเป็นคนที่มีความเสมอภาคเกี่ยวกับภาษาที่ฉันพูดถึง :) และตกลงกันแล้วดูเหมือนว่าเรื่องราวจะเหมือนกับ Python ยกเว้นเมื่อไม่กี่ปีที่ผ่านมา
— Jesse Millikan
1
Perl ได้มีคู่ของซอก สิ่งแรกสุดนั้นสะท้อนอยู่ในเอกสารเวอร์ชันเก่าซึ่งอ้างถึงชื่อว่าเป็นตัวย่อสำหรับ "การสกัดและการรายงานภาษา" คนที่สองมาพร้อมบิตต่อมาและเป็น CGI สคริปต์ - เป็นเวลาหลายปี, Perl เป็นภาษาของเว็บ เห็นได้ชัดว่าตอนนี้ความนิยมลดลงไปมากแล้ว แต่ดูที่เว็บไซต์เก่าที่ยังคงใช้งานซอฟต์แวร์เดิมที่สร้างขึ้นด้วยตัวเองและคุณจะเห็น Perl มากมาย (ฉันคิดถึง slashdot.org ตอนนี้ แต่มีอีกไม่กี่)
— จูลส์
8

ด้วยเหตุผลเดียวกันกับ Lisp ที่ไม่เคยถูกจับได้เลย ฟังก์ชั่นการเขียนโปรแกรมเป็นกระบวนทัศน์มนุษย์ต่างดาวมากเมื่อเทียบกับการเขียนโปรแกรมเชิงวัตถุและเชิง ถ้าเช่นเดียวกับนักเรียน CS ส่วนใหญ่คุณเริ่มต้นด้วย C และก้าวหน้าไปสู่ ​​C ++ / Java คุณมักจะไม่ต้องการเรียนรู้ที่จะคิดในลักษณะที่เป็นมุมฉากกับวิธีที่คุณคิด

— Chinmay Kanchi
แหล่งที่มา
2
กระบวนทัศน์ของมนุษย์ต่างดาว? มันใกล้เคียงกับคณิตศาสตร์มากกว่าการเขียนโปรแกรมที่จำเป็นคือ ที่นี่ในสวีเดนฉันคิดว่านักเรียน CS ที่มหาวิทยาลัยส่วนใหญ่จะมีโปรแกรมที่ใช้งานได้ก่อน เช่นเราเริ่มต้นด้วย Standard ML ก่อนหน้า C, Erlang และ Java
— Jonas
4
ยุติธรรมพอสมควร ฉันรู้ว่านักเรียนวิศวกรรมจำนวนมากในสหราชอาณาจักรและอินเดียได้รับการสอน C ก่อนตามด้วย C ++ และ / หรือ Java บ่อยครั้งที่พวกเขาไม่ได้สอนภาษาที่ใช้งานได้เลย
— Chinmay Kanchi
13
@Jonas สำหรับชาวบ้านจำนวนมากคณิตศาสตร์เป็นกระบวนทัศน์ของมนุษย์ต่างดาวและทุกอย่างที่ใช้การเขียนโปรแกรมไกลออกไปจากคณิตศาสตร์ทำให้เข้าใจง่ายขึ้น
— scriptocalypse
5
ฉันได้ยินคนที่ไม่เคยได้ยินเรื่องต้นไม้ฟังคนเดียวเขียนโปรแกรมฟังก์ชั่นจบการศึกษา
— dan_waterworth
1
@ Tux-D ที่จริงแล้วฉันกำลังพูดถึงนักเรียนในสหราชอาณาจักร
— dan_waterworth
6

ลองพิจารณาธุรกิจและการเขียนโปรแกรม

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

ยิ่งไปกว่านั้นในธุรกิจสิ่งที่ถูกที่สุดคือสิ่งที่พวกเขาทำเมื่อวาน อย่างไรก็ตามการเปลี่ยนแปลงที่พึงประสงค์มีราคาแพง หาก บริษัท ต้องเปลี่ยนจากพูดว่า C # /. NET solution แม้แต่ F # พวกเขาจะมีปัญหา โปรแกรมเมอร์ของพวกเขา (ซึ่งไม่น่าจะเป็นโปรแกรมเมอร์ที่เก่งที่สุด) จะต้องเรียนรู้ภาษาใหม่และมีความเชี่ยวชาญทั้งสองและใช้ทั้งสองอย่างบ่อยๆ จะมีการเขียนตามปกติทั้งในระยะเวลานาน ถ้าพวกเขาต้องย้ายไปที่อื่นเช่น Haskell หรือถ้าพวกเขาใช้ C ++ / MFC ในตอนแรกพวกเขาจะเปลี่ยนไปมากขึ้นและนั่นจะแพงกว่ามาก

นอกจากนี้ยังมีอุปทานของโปรแกรมเมอร์ C # และการสนับสนุน Microsoft อย่างต่อเนื่องเป็นเวลานาน แนวทางปฏิบัติด้านไอทีในปัจจุบันสามารถนับได้ ไม่มีการสนับสนุนระดับสถาบันหรือการรับประกันความพร้อมของโปรแกรมเมอร์อย่างต่อเนื่อง

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

— เดวิด ธ อร์นลีย์
แหล่งที่มา
2

คุณเขียนโค้ดในรูปแบบการใช้งานแล้วคุณก็ไม่รู้

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

ฉันคิดว่าภาษาที่ใช้งานได้นั้น จำกัด มากเกินไป ดังนั้นแทนที่จะแทนที่ภาษาที่จำเป็นด้วยฟังก์ชันที่ใช้งานได้ภาษาที่จำเป็นจะได้รับคุณลักษณะที่ใช้งานได้ ปัจจุบันเกือบทุกภาษาการเขียนโปรแกรมมีการปิดและแกะ

— Calmarius
แหล่งที่มา
1

ฉันเชื่อว่ามีคำตอบจริงสำหรับคำถามของคุณ คุณสามารถค้นหาสาเหตุที่เกี่ยวข้องได้มากมายว่าทำไมคำตอบนี้เป็นจริง แต่เป็นคำถามที่ต่างกัน

นี่มันคือ:

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

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

— จอห์นฟิชเชอร์
แหล่งที่มา
0

ปัญหาที่แท้จริงคือสถานะ

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

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

ดังนั้นแม้ว่าภาษาที่ใช้งานจะไม่มีสถานะโกลบอล แต่ข้อมูลสถานะจะถูกส่งเป็นพารามิเตอร์และผลลัพธ์

ดังนั้นคำถามจะกลายเป็นภาษาที่สามารถจัดการกับรัฐได้อย่างมีประสิทธิภาพอยู่เบื้องหลังความรู้สึก? โดยเฉพาะอย่างยิ่งเมื่อขนาดข้อมูลไกลเกินขนาดของสถาปัตยกรรม

มองจากด้านฮาร์ดแวร์

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

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

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

มองจากด้านอุตสาหกรรม:

อุตสาหกรรมมีโปรแกรมเมอร์เต็มรูปแบบที่ไม่มีประสิทธิภาพ

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

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

ดังนั้นสำหรับอุตสาหกรรมฉันคิดว่ามันขึ้นอยู่กับความสามารถในการวัดการปรับปรุงในรหัส

จากมุมมองการจ้างงาน

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

— มาร์ตินยอ
แหล่งที่มา
2
ภาษาที่ใช้งานได้โดยเฉพาะอย่างยิ่งภาษาที่ไม่บริสุทธิ์สามารถใช้งานได้กับสถานะโลกที่สมบูรณ์แบบ ฉันพบว่าบ่อยครั้งที่โปรแกรมย่อยสลายเป็นเลเยอร์สลับ: เช่นสถานะโกลบอล ... แต่การเปลี่ยนสถานะการทำงาน ... ด้วยสถานะท้องถิ่น (ปิดบัง) เพื่อใช้ส่วนที่สำคัญต่อประสิทธิภาพของช่วงการเปลี่ยนภาพเหล่านั้น ฯลฯ ปัญหาเกี่ยวกับภาษาที่จำเป็น IMO คือพวกเขามักจะทำให้โปรแกรมเมอร์ใช้สถานะที่ไม่เหมาะสมเมื่อรูปแบบการทำงานจะทำงานได้ดีขึ้น แต่ภาษาดูเหมือนจะพัฒนาไปในทิศทางที่สนับสนุนทั้งสองสไตล์ได้ดี
— Ryan Culpepper
1
มันง่ายมากที่จะจัดการกับสถานะในภาษาที่ใช้งานได้ แต่ต้องมีการเปลี่ยนแปลงในการเน้น โดยที่ในภาษาที่จำเป็นคุณจะเขียนโพรซีเดอร์ที่แก้ไขสถานะในภาษาที่ใช้งานได้คุณจะเขียนฟังก์ชันที่ส่งคืนโพรซีเดอร์ที่แก้ไขสถานะ
— dan_waterworth
"ภาษาที่ใช้งานได้ไม่มีสถานะโกลบอล" - คุณไม่จำเป็นต้องมีสถานะโกลบอล การจัดการของรัฐนั้นทำได้ง่ายด้วยพระ
— Arunav Sanyal
-3

คำถามนี้มีหลักฐานผิดเล็กน้อย ด้วยเหตุผลดังต่อไปนี้:

  1. การเขียนโปรแกรมฟังก์ชั่นเป็นเรื่องธรรมดาในอุตสาหกรรม แต่ใช้เฉพาะเมื่อโปรแกรมเมอร์มีประสบการณ์เท่านั้น ผู้เริ่มต้นไม่สามารถคาดหวังได้ว่าจะรู้ เกือบทุกโครงการการเขียนโปรแกรมขนาดใหญ่ใช้งานอยู่ แต่พวกเขาเพียงเก็บไว้ในพื้นที่ที่จัดการโดยโปรแกรมเมอร์ที่มีประสบการณ์ ผู้เริ่มต้นจะจัดการกับโมดูลง่าย ๆ ซึ่งไม่จำเป็นต้องมีการเขียนโปรแกรมการทำงาน
  2. จากความเป็นจริงนี้ บริษัท ที่จ้างคน (โดยปกติแล้วคนหนุ่มสาวที่มาจากมหาวิทยาลัย) ไม่สามารถขอประสบการณ์การเขียนโปรแกรมที่ทำงานได้ ทุกคนในโครงการที่ต้องมีการเขียนโปรแกรมการทำงานอยู่ใน บริษัท เดียวกันมา 15 ปีแล้ว
  3. มหาวิทยาลัยเริ่มสอนเพราะตอนนี้พวกเขารู้แล้วว่าความรู้ด้านการเขียนโปรแกรมเชิงปฏิบัติจะมีประโยชน์มากใน 30 ปี ช่วงเวลาของพวกเขาคือ 30 ปีไม่ใช่ครึ่งปีปกติเหมือนใน บริษัท
  4. ประเด็นเหล่านี้เป็นสาเหตุที่ทำให้ผู้คนผิดหวังเมื่อพวกเขาเข้าทำงานและเห็นว่าสิ่งที่พวกเขาเรียนรู้ในมหาวิทยาลัยไม่ได้ใช้ แต่พวกเขาถูกออกแบบมาเป็นเวลา 30 ปีและมันจะมีประโยชน์ในที่สุด - เป็นเพียงแค่ บริษัท ที่ใช้สิ่งง่าย ๆ - สิ่งที่พวกเขาสามารถคาดหวังให้คนรู้
  5. ถ้าคุณคิดว่าหลังจากเรียนจบมหาวิทยาลัยไปสองสามปีคุณจะรู้ว่าการเขียนโปรแกรมใช้งานได้ดีพอที่จะใช้ในโครงการซอฟต์แวร์จริง เริ่มจากสิ่งง่าย ๆ ก่อน คุณไม่จำเป็นต้องทำซอฟต์แวร์ที่ซับซ้อนที่สุดเป็นงานแรกของคุณเมื่อคุณเริ่มทำงาน ในที่สุดคุณจะได้สิ่งที่ซับซ้อน แต่ต้องใช้เวลา
— TP1
แหล่งที่มา
2
1) "โครงการการเขียนโปรแกรมขนาดใหญ่เกือบทั้งหมดใช้มัน" ประสบการณ์ของฉันคือว่ามันอยู่ไกลจาก reallity มี บริษัท น้อยมากที่ใช้การเขียนโปรแกรมใช้งานได้ตามที่ฉันรู้ ส่วนใหญ่จะใช้ Java และ C # (แม้ว่า C # ได้มีโครงสร้างการทำงานมากขึ้นไม่กี่ปีที่ผ่านมา), C ++ และ C
— โจนัส
2
2)ประสบการณ์ของฉันตรงกันข้าม คนจากมหาวิทยาลัยดูเหมือนจะเป็นคนเดียวที่รู้การเขียนโปรแกรมการทำงาน ที่นี่ในสวีเดนมหาวิทยาลัยส่วนใหญ่สอนการเขียนโปรแกรมเชิงหน้าที่ตั้งแต่ปีแรก และมหาวิทยาลัยอย่าง MIT ได้ใช้โปรแกรมเชิงฟังก์ชันในหลักสูตรการเขียนโปรแกรมแรกของพวกเขา (Scheme)
— Jonas
@ โจนัส: ไม่ภาษาการเขียนโปรแกรมไม่เกี่ยวข้องกับมัน แน่นอนว่า C และ C ++ และ java ฯลฯ นั้นถูกใช้งานโดยโปรเจ็คต์จำนวนมาก การเขียนโปรแกรมการทำงานยังทำงานในรหัส c ++ การปฏิบัติในปัจจุบันดูเหมือนว่าเป็นส่วนหนึ่งของโครงการที่ใช้ OO และเป็นส่วนหนึ่งของมันใช้การเขียนโปรแกรมการทำงาน ทั้งสองส่วนใช้ภาษาเดียวกัน (โดยปกติคือ c / c ++)
— tp1
ใช่คุณสามารถทำ OO ใน C ได้เช่นกัน แต่ไม่แนะนำ C และ C ++ ไม่มีโครงสร้างจำนวนมากสำหรับการเขียนโปรแกรมที่ใช้งานได้เช่นไม่เปลี่ยนแปลงไม่ได้โดยค่าเริ่มต้นไม่รองรับการจับคู่รูปแบบที่ดีไม่มีโครงสร้างข้อมูลที่ไม่เปลี่ยนรูปแบบและอื่น ๆ ...
— Jonas
นั่นคือเหตุผลที่มันต้องการโปรแกรมเมอร์ที่มีประสบการณ์ เนื่องจากมันเป็นไปไม่ได้ที่จะเปลี่ยนภาษาการเขียนโปรแกรมจากภาษากระแสหลักสิ่งที่ดีที่สุดถัดไปคือการทำโปรแกรมการทำงานใน c ++ c ++ ยังมีสิ่งต่าง ๆ เช่น const ซึ่งช่วยได้ค่อนข้างมาก
— tp1
-10

เพราะมันยากที่จะ debug FP

— Interstar
แหล่งที่มา
11
ฉันไม่เห็นด้วย. กระบวนการที่ดีบั๊กนั้นง่ายกว่า บางทีคุณอาจคิดว่ามันยากขึ้นเพราะกระบวนทัศน์การทำงานแตกต่างกันและต้องการประสบการณ์ที่จะคุ้นเคยกับวิธีการทำสิ่งใหม่ ๆ รวมถึงการดีบั๊ก
— Maniero
2
ภาษาโปรแกรมการทำงานนั้นง่ายต่อการทดสอบจริง ๆ
— Jonas
4
โจนัสฉันไม่ได้พูดว่า "ทดสอบ" ฉันพูดว่า "ดีบั๊ก" ค้นหาข้อผิดพลาดที่คุณทำ การทดสอบเป็นส่วนหนึ่งของสิ่งนั้น แต่ก็มีเหตุผลเกี่ยวกับโปรแกรมและอื่น ๆ ที่เป็นที่รู้จักมาก - ฉันเป็นผู้สนับสนุน มันเป็นฟังก์ชั่นของพลังของ FP ยิ่งรหัสใดบรรทัดหนึ่งทำงานได้มากเท่าไหร่ก็ยิ่งยากขึ้นเท่านั้นที่จะเห็นบรรทัดของรหัสที่ทำให้เกิดปัญหา การแมประหว่างบรรทัดของโค้ดและเอฟเฟกต์นั้นจะกระจายไปมาก ฟังก์ชั่นการสั่งซื้อที่สูงกว่าอาจสัมผัสกับพฤติกรรมหลายอย่างของโปรแกรมและในทางกลับกัน อาการอาจแตกต่างกันอย่างมากระหว่างจุดต่าง ๆ สำหรับข้อผิดพลาดเดียวกัน
— interstar
จากประสบการณ์ของฉันมันไม่ยากที่จะทำการดีบักเลย ฉันใช้ F # และหาเหตุผลไม่ได้ว่าทำไมคุณถึงพบว่าการ debug นั้นยากกว่า C # อาจเป็นการดีบั๊กใน Haskell เนื่องจากความเกียจคร้าน (ฉันไม่รู้) แต่การโปรแกรม FP ที่กระตือรือร้นนั้นง่ายกว่าเนื่องจากไร้สัญชาติอย่างโจนาสกล่าว กล่าวอีกนัยหนึ่งรหัส FP สามารถคาดเดาได้มากกว่าเพราะคุณรู้ว่าผลลัพธ์ไม่ได้รับอิทธิพลจากตัวแปรที่มองไม่เห็น
— Muhammad Alkarouri
2
ตราบใดที่ฟังก์ชั่นของคุณบริสุทธิ์การแก้จุดบกพร่องก็ง่าย หากคุณไม่สามารถดีบักได้โดยการเพิ่มการทดสอบหน่วยดังนั้นการสอบข้อเขียนของคุณจึงไม่เพียงพอ
— dan_waterworth
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.