ข้อเสียเปรียบสำหรับการอนุมานประเภทคืออะไร

29

ดูเหมือนว่าภาษาการเขียนโปรแกรมใหม่ทั้งหมดหรืออย่างน้อยก็เป็นภาษาที่ได้รับความนิยมอย่างมาก แม้จาวาสคริปต์ก็มีประเภทและการอนุมานประเภทแม้ว่าการใช้งานที่หลากหลาย (Acscript, typescript ฯลฯ ) มันดูดีสำหรับฉัน แต่ฉันสงสัยว่ามีการแลกเปลี่ยนหรือทำไมสมมติว่า Java หรือภาษาดีเก่าไม่มีการอนุมานประเภท

เมื่อประกาศตัวแปรในGoโดยไม่ระบุประเภทของมัน (ใช้ var โดยไม่มี type หรือ: = ไวยากรณ์) ชนิดของตัวแปรจะถูกอนุมานจากค่าทางด้านขวามือ
Dอนุญาตให้เขียนแฟรกเมนต์โค้ดขนาดใหญ่โดยไม่ระบุชนิดซ้ำซ้อนเช่นเดียวกับภาษาไดนามิก ในทางกลับกันการอนุมานแบบคงที่จะอนุมานประเภทและคุณสมบัติของรหัสอื่น ๆ ที่ให้สิ่งที่ดีที่สุดทั้งในโลกที่คงที่และแบบไดนามิก
เอ็นจิ้นการอนุมานประเภทในRustค่อนข้างฉลาด มันทำมากกว่าดูประเภทของค่า r ในระหว่างการเริ่มต้น นอกจากนี้ยังมีลักษณะการใช้ตัวแปรหลังจากนั้นอนุมานชนิดของมัน
Swiftใช้การอนุมานประเภทเพื่อกำหนดประเภทที่เหมาะสม การอนุมานประเภทช่วยให้ผู้รวบรวมสามารถอนุมานประเภทของนิพจน์เฉพาะโดยอัตโนมัติเมื่อคอมไพล์โค้ดของคุณเพียงแค่ตรวจสอบค่าที่คุณให้ไว้

programming-languages type-systems

— ผู้ใช้ที่ไม่มีหมวก
แหล่งที่มา

3

ใน C # คำแนะนำทั่วไปบอกว่าไม่ได้ใช้เสมอvarเพราะบางครั้งอาจทำให้อ่านไม่ได้

— Mephy

5

"... หรือเพราะเหตุใดสมมติว่า Java หรือภาษาดีเก่าไม่มีการอนุมานประเภท" เหตุผลอาจเป็นประวัติศาสตร์ ML ปรากฏ 1 ปีหลังจาก C ตามวิกิพีเดียและมีการอนุมานประเภท Java ได้รับการพยายามที่จะอุทธรณ์ไปยังนักพัฒนา c ++ C ++ เริ่มเป็นส่วนเสริมของ C และข้อกังวลหลักของ C คือการห่อหุ้มแบบพกพาเหนือชุดประกอบและง่ายต่อการรวบรวม สำหรับสิ่งที่มันคุ้มค่าฉันได้อ่าน subtyping ทำให้อนุมานประเภท undecidable ในกรณีทั่วไปเช่นกัน

— Doval

3

@Doval Scala ดูเหมือนว่าจะทำงานได้ดีในประเภทอนุมานสำหรับภาษาที่รองรับการสืบทอดชนิดย่อย มันไม่ดีเท่าภาษาตระกูล ML ใด ๆ แต่มันอาจจะดีเท่าที่คุณจะขอได้เนื่องจากการออกแบบของภาษา

— KChaloux

12

มันคุ้มค่าที่จะวาดความแตกต่างระหว่างการลดประเภท (monodirectional เช่น C # varและ C ++ auto) และการอนุมานประเภท (สองทิศทางเช่น Haskell let) ในกรณีก่อนหน้าประเภทของชื่ออาจถูกอนุมานจากผู้เริ่มต้นเท่านั้นการใช้จะต้องเป็นไปตามประเภทของชื่อ ในกรณีหลังประเภทของชื่ออาจถูกอนุมานจากการใช้งานด้วย - ซึ่งมีประโยชน์ในการที่คุณสามารถเขียนเพียง[]สำหรับลำดับที่ว่างเปล่าโดยไม่คำนึงถึงประเภทองค์ประกอบหรือnewEmptyMVarสำหรับการอ้างอิงโมฆะ null ใหม่โดยไม่คำนึงถึงผู้อ้างอิง ชนิด

— Jon Purdy

การอนุมานประเภทนั้นซับซ้อนอย่างไม่น่าเชื่อในการนำมาใช้โดยเฉพาะอย่างยิ่งมีประสิทธิภาพ ผู้คนไม่ต้องการให้ความซับซ้อนในการคอมไพล์ของพวกเขาประสบกับการระเบิดอย่างทวีคูณจากการแสดงออกที่ซับซ้อนมากขึ้น อ่านที่น่าสนใจ: cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

— Alexander - Reinstate Monica

43

ระบบประเภทของ Haskell นั้นมีข้อด้อยอย่างสมบูรณ์ (ทิ้ง polymorphic recursion ส่วนขยาย ภาษา บางอย่างและข้อ จำกัด monomorphism ที่หวั่นกลัว) แต่โปรแกรมเมอร์ก็ยังให้คำอธิบายประกอบประเภทไว้ในซอร์สโค้ดแม้ว่าพวกเขาจะไม่ต้องการก็ตาม ทำไม?

คำอธิบายประกอบชนิดทำหน้าที่เป็นเอกสาร นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งกับประเภทที่แสดงออกเช่นเดียวกับ Haskell ด้วยชื่อและประเภทของฟังก์ชั่นคุณมักจะคาดเดาได้ดีว่าฟังก์ชันทำอะไรโดยเฉพาะอย่างยิ่งเมื่อฟังก์ชันนั้นมีความแปรผัน
คำอธิบายประกอบประเภทสามารถผลักดันการพัฒนา การเขียนลายเซ็นประเภทก่อนที่คุณจะเขียนเนื้อความของฟังก์ชันให้ความรู้สึกเหมือนกับการพัฒนาโดยใช้การทดสอบ จากประสบการณ์ของฉันเมื่อคุณสร้างฟังก์ชั่น Haskell แล้วคอมไพล์มันจะใช้งานได้ครั้งแรก (แน่นอนว่านี่ไม่ได้เป็นการยกเลิกการทดสอบอัตโนมัติ!)
ประเภทอย่างชัดเจนสามารถช่วยคุณตรวจสอบสมมติฐานของคุณ เมื่อฉันพยายามที่จะเข้าใจรหัสที่ใช้งานได้แล้วฉันมักจะพริกไทยกับสิ่งที่ฉันเชื่อว่าเป็นคำอธิบายประกอบประเภทที่ถูกต้อง หากรหัสยังคงรวบรวมฉันรู้ว่าฉันเข้าใจมัน หากไม่เป็นเช่นนั้นฉันอ่านข้อความแสดงข้อผิดพลาด
ลายเซ็นประเภทให้คุณมีความเชี่ยวชาญฟังก์ชั่น polymorphic บางครั้ง API อาจแสดงออกหรือมีประโยชน์มากขึ้นหากฟังก์ชั่นบางอย่างไม่ใช่ polymorphic คอมไพเลอร์จะไม่บ่นถ้าคุณให้ฟังก์ชั่นประเภททั่วไปน้อยกว่าที่จะอนุมาน map :: (a -> b) -> [a] -> [b]ตัวอย่างคลาสสิกเป็น รูปแบบทั่วไปมากขึ้น ( fmap :: Functor f => (a -> b) -> f a -> f b) ใช้กับFunctors ทั้งหมดไม่ใช่เฉพาะรายการ แต่รู้สึกว่าmapมันจะง่ายต่อการเข้าใจสำหรับผู้เริ่มต้นดังนั้นจึงอาศัยอยู่ข้างๆพี่ใหญ่

ในภาพรวมข้อเสียของระบบที่พิมพ์แบบคงที่ แต่มีข้อด้อยเป็นแบบเดียวกับข้อเสียของการพิมพ์แบบสแตติกโดยทั่วไปการสนทนาที่สวมใส่อย่างดีบนเว็บไซต์นี้และอื่น ๆ (Googling "ข้อเสียการพิมพ์แบบคงที่") ของหน้าเพลิงสงคราม) แน่นอนว่าข้อเสียบางประการนั้นได้รับการแก้ไขโดยคำอธิบายประกอบประเภทที่น้อยลงในระบบที่มีข้อด้อย นอกจากนี้การอนุมานประเภทมีข้อดีของตัวเอง: การพัฒนาที่ขับเคลื่อนด้วยรูจะเป็นไปไม่ได้หากไม่มีการอนุมานประเภท

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

_{* แม้แต่ Java ซึ่งเป็นแพะรับบาปที่ยอดเยี่ยมก็สามารถทำการอนุมานประเภทท้องถิ่นได้จำนวนหนึ่ง ในคำสั่งเช่นMap<String, Integer> = new HashMap<>();คุณไม่จำเป็นต้องระบุประเภททั่วไปของตัวสร้าง ในทางกลับกันภาษาสไตล์ ML นั้นโดยทั่วไปแล้วจะมีความเลวร้ายระดับโลก}

— Benjamin Hodgson
แหล่งที่มา

2

แต่คุณไม่ได้เริ่มต้น;) คุณต้องมีความเข้าใจในการเรียนประเภทและชนิดก่อนที่คุณจริงๆ Functor"รับ" รายการและmapมีแนวโน้มที่จะคุ้นเคยกับ Haskellers ที่ไม่ได้ปรุงแต่ง

— Benjamin Hodgson

1

คุณคิดว่า C # varเป็นตัวอย่างของการอนุมานประเภทหรือไม่

— Benjamin Hodgson

1

ใช่ C # varเป็นตัวอย่างที่เหมาะสม

— Doval

1

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

— Doval

1

โปรดทราบว่าซินnew HashMap<>();แท็กซ์ถูกเพิ่มเฉพาะใน Java 7 และ lambdas ใน Java 8 อนุญาตการอนุมานประเภท "ของจริง" ค่อนข้างมาก

— Michael Borgwardt

8

ใน C # การอนุมานชนิดเกิดขึ้น ณ เวลาคอมไพล์ดังนั้นต้นทุนรันไทม์จึงเป็นศูนย์

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

var s = new SomeReallyLongTypeNameWith<Several, Type, Parameters>(andFormal, parameters);

โดยที่คุณจะได้รับการทำซ้ำชื่อของคุณนานจริงๆประเภท (และพารามิเตอร์ชนิด) varมากกว่าเพียงแค่การบอกว่า

ใช้ชื่อจริงของประเภทเมื่อชัดเจนปรับปรุงรหัสชัดเจน

มีบางสถานการณ์ที่ไม่สามารถใช้การอนุมานประเภทได้เช่นการประกาศตัวแปรสมาชิกซึ่งมีการตั้งค่า ณ เวลาการก่อสร้างหรือที่คุณต้องการให้ระบบ Intellisense ทำงานได้อย่างถูกต้อง (IDE ของ Hackerrank จะไม่ intellisense สมาชิกของตัวแปรยกเว้นว่าคุณประกาศชนิดอย่างชัดเจน) .

— โรเบิร์ตฮาร์วีย์
แหล่งที่มา

16

"ใน C # การอนุมานชนิดเกิดขึ้น ณ เวลาคอมไพล์ดังนั้นราคารันไทม์จึงเป็นศูนย์" การอนุมานประเภทเกิดขึ้นในเวลาคอมไพล์โดยคำจำกัดความดังนั้นในทุกภาษา

— Doval

ดีกว่ามาก

— Robert Harvey

1

@Doval เป็นไปได้ที่จะทำการอนุมานประเภทในระหว่างการรวบรวม JIT ซึ่งชัดเจนว่ามีต้นทุนรันไทม์

— จูลส์

6

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

— Doval

7

คำถามที่ดี!

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

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

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

1

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

— DeadMG

2

@deadmg - แน่นอนว่าเมื่อตัวแปรถูกประกาศว่าไม่มีปัญหา แต่ในขณะที่คุณพิมพ์ในการประกาศตัวแปรมันไม่สามารถ จำกัด ตัวเลือกของทางด้านขวามือให้แคบลงสำหรับประเภทที่ประกาศเนื่องจากไม่มีประเภทที่ประกาศ

— Telastyn

@deadmg - สำหรับ lambdas ฉันไม่ชัดเจนในสิ่งที่คุณหมายถึง แต่ฉันค่อนข้างแน่ใจว่ามันไม่ถูกต้องทั้งหมดขึ้นอยู่กับความเข้าใจของฉันเกี่ยวกับการทำงานของสิ่งต่าง ๆ แม้แต่สิ่งที่เรียบง่ายvar foo = x => x;ล้มเหลวเพราะภาษาจำเป็นต้องอนุมานxที่นี่และไม่มีอะไรดำเนินการ เมื่อสร้างแลมบ์ดาแล้วพวกเขาจะถูกสร้างขึ้นตามตัวแทนที่ได้รับการพิมพ์อย่างชัดเจนFunc<int, int> foo = x => xถูกสร้างขึ้นใน CIL Func<int, int> foo = new Func<int, int>(x=>x);ซึ่งเป็นที่แลมบ์ดาถูกสร้างขึ้นเป็นฟังก์ชั่นที่สร้างขึ้นและพิมพ์อย่างชัดเจน สำหรับฉันการอนุมานประเภทของการอนุมานxเป็นส่วนหนึ่งและพัสดุ ...

— Telastyn

3

@Telastyn มันไม่เป็นความจริงเลยที่ภาษาไม่มีอะไรจะดำเนินต่อไป ข้อมูลทั้งหมดที่จำเป็นในการพิมพ์นิพจน์x => xนั้นอยู่ในแลมบ์ดาเอง - มันไม่ได้อ้างถึงตัวแปรใด ๆ จากขอบเขตโดยรอบ สติภาษาใด ๆ ทำงานได้อย่างถูกต้องจะอนุมานได้ว่าชนิดของมันคือ "สำหรับทุกประเภทa, a -> a" ฉันคิดว่าสิ่งที่ DeadMG พยายามจะพูดคือระบบประเภทของ C # ไม่มีคุณสมบัติประเภทหลักซึ่งหมายความว่าเป็นไปได้ที่จะคิดประเภททั่วไปที่สุดสำหรับนิพจน์ใด ๆ มันเป็นคุณสมบัติที่ทำลายได้ง่ายมาก

— Doval

@Doval - เพิ่ม ... ไม่มีสิ่งใดเป็นวัตถุฟังก์ชั่นทั่วไปใน C # ซึ่งฉันคิดว่าแตกต่างอย่างละเอียดกว่าสิ่งที่คุณทั้งคู่พูดถึงแม้ว่ามันจะนำไปสู่ปัญหาเดียวกัน

— Telastyn

4

มันดูดีสำหรับฉัน แต่ฉันสงสัยว่ามีการแลกเปลี่ยนหรือทำไมสมมติว่า Java หรือภาษาดีเก่าไม่มีการอนุมานประเภท

Java เกิดขึ้นเป็นข้อยกเว้นมากกว่ากฎที่นี่ แม้แต่ C ++ (ซึ่งฉันเชื่อว่ามีคุณสมบัติเป็น "ภาษาเก่าที่ดี" :)) รองรับการอนุมานประเภทด้วยautoคำหลักตั้งแต่มาตรฐาน C ++ 11 มันไม่เพียงทำงานร่วมกับการประกาศตัวแปร แต่ยังเป็นประเภทการคืนค่าฟังก์ชันซึ่งมีประโยชน์อย่างยิ่งกับฟังก์ชั่นเทมเพลตที่ซับซ้อน

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

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

ฉันไม่เห็นข้อเสียเปรียบที่แท้จริงในการให้โอกาสแก่นักพัฒนาในการใช้การอนุมานประเภท

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

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

— Gábor Angyal
แหล่งที่มา

1

ความแตกต่างหลักระหว่างระบบการอนุมานของ Hindley-Milner และการอนุมานแบบ Go-style คือทิศทางของการไหลของข้อมูล ใน HM พิมพ์ข้อมูลที่ไหลไปข้างหน้าและข้างหลังผ่านการรวม ใน Go ให้พิมพ์ data flow ไปข้างหน้าเท่านั้น: คำนวณการส่งต่อการแทนที่เท่านั้น

การอนุมานประเภท HM เป็นนวัตกรรมที่ยอดเยี่ยมที่ทำงานได้ดีกับภาษาที่ใช้พิมพ์ได้หลากหลาย แต่ผู้เขียนของ Go อาจจะโต้แย้งว่ามันพยายามทำมากเกินไป:

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

— Edward Z. Yang
แหล่งที่มา

2

น่าเสียดายนี่เป็นคำตอบที่ดีสำหรับคำถามอื่น OP ถามเกี่ยวกับ "การอนุมานแบบ Go-style" กับภาษาที่ไม่มีการอนุมานแบบใดเลยไม่ใช่ "Go-style" เปรียบเทียบกับ HM

— Ixrec

-2

มันเจ็บการอ่าน

เปรียบเทียบ

var stuff = someComplexFunction()

VS

List<BusinessObject> stuff = someComplexFunction()

มันเป็นปัญหาโดยเฉพาะอย่างยิ่งเมื่ออ่านนอก IDE เหมือนใน GitHub

— มิเกล
แหล่งที่มา

4

นี้ไม่ได้ดูเหมือนจะนำเสนออะไรที่สำคัญกว่าจุดทำและอธิบายในก่อน 6 คำตอบ

— ริ้น

หากคุณใช้ชื่อที่เหมาะสมแทน "ซับซ้อนไม่สามารถอ่านได้" คุณvarสามารถใช้ชื่อได้โดยไม่ทำร้ายการอ่าน var objects = GetBusinessObjects();

— Fabio

ตกลง แต่คุณกำลังรั่วระบบประเภทลงในชื่อตัวแปร มันเหมือนสัญกรณ์ฮังการี หลังจาก refactorings คุณมีแนวโน้มที่จะจบลงด้วยชื่อที่ไม่ตรงกับรหัส โดยทั่วไปสไตล์การใช้งานจะทำให้คุณสูญเสียความได้เปรียบในการกำหนดเนมสเปซตามธรรมชาติที่คลาสมีให้ ดังนั้นคุณจะจบด้วย squareArea () แทนที่จะเป็น square.area ()

— มิเกล