ภาษาการเขียนโปรแกรมใดที่สร้างบั๊กที่หายากได้น้อยที่สุด? [ปิด]

54

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

โดยส่วนตัวฉันพบว่าฉันใช้เวลาน้อยมากในการค้นหาข้อผิดพลาดที่แปลกประหลาดในโปรแกรม Java และ C # ในขณะที่รหัส C ++ มีชุดข้อผิดพลาดที่เกิดซ้ำและ Python / คล้ายคลึงกันมีชุดของตัวเองของข้อผิดพลาดทั่วไปและโง่ ๆ ในภาษาอื่น ๆ

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

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

ยกโทษให้ฉันหากนี่เป็นสิ่งที่ซ้ำกัน แต่ฉันไม่พบสิ่งใดในหัวข้อเฉพาะนี้

— Magnus Wolffelt
แหล่งที่มา

10

ฉันต้องการดูงานวิจัยบางอย่างที่ทำในหัวข้อนี้! ไม่ใช่แค่ "หลักฐานพอสังเขปของฉันแสดงให้เห็นว่าภาษาเดียวที่ฉันรู้คือราชา" แต่อัตราบั๊กจากโครงการขนาดใหญ่และอื่น ๆ

— Frank Shearar

@ Frank .. ถ้าคุณมีจำนวนมาก (และฉันหมายถึงมาก) เวลาคุณอาจสร้างสถิติจาก ohloh ถ้าคุณสามารถระบุแพทช์ที่แก้ไขข้อบกพร่องจากที่เก็บรหัสนับพัน

— Tim Post

หนึ่งเดียวที่อนุญาตให้แสดงความคิดเห็นได้เท่านั้น ไม่มีคำแนะนำอื่น ๆ :)

— Victor Hurdugaci

4

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

— Winston Ewert

@Winston เห็นด้วย

— Magnus Wolffelt

58

ยิ่งระบบพิมพ์ภาษามีประสิทธิภาพมากเท่าไหร่ก็ยิ่งมีข้อบกพร่องมากขึ้นในเวลารวบรวมเท่านั้น

รูปต่อไปนี้เปรียบเทียบภาษาการเขียนโปรแกรมที่รู้จักกันดีบางประการในแง่ของพลังความเรียบง่ายและความปลอดภัยของระบบการพิมพ์ [ ที่มา ]

ข้อความแสดงแทน

* แฟคตอริ่งในความสามารถในการใช้โครงสร้างที่ไม่ปลอดภัย

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

ฉันได้ทำเครื่องหมาย Haskell '98 ว่าบริสุทธิ์ แต่ GHC Haskell ไม่บริสุทธิ์เนื่องจากฟังก์ชันที่ไม่ปลอดภัย * หากคุณปิดการใช้งานที่ไม่ปลอดภัย * ให้กระโดด GHC Haskell ขึ้นตามลำดับ

— หายไปฟากฟ้า
แหล่งที่มา

8

มันยอดเยี่ยมมาก!

7

ฉันไม่พบ Common LISP ในกราฟิก: (let ((itbe '())) ... )...

— duros

7

อะไร? ไม่มีที่ว่างเหลืออยู่ทางด้านซ้ายสำหรับ PHP ใช่ไหม

— pestaa

7

C # อนุญาตให้พอยน์เตอร์ที่ปลอดภัย : ตรวจสอบการคำนวณทางคณิตศาสตร์ทั้งหมดแล้ว ดังนั้นฉันเชื่อว่ามันควรจะอยู่ที่นั่นกับ Java

— Alex สิบ Brink

11

@missingfaktor: ฉันคิดว่า C # อยู่ในตำแหน่งที่ไม่ดี C # อนุญาตและส่งเสริมรูปแบบการเขียนโปรแกรมที่ปลอดภัยยิ่งขึ้น ไม่ควรวัดจากสิ่งที่แย่ที่สุดที่อนุญาต

— back2dos

20

ในความเห็นของฉัน Haskell ช่วยให้คุณหลีกเลี่ยงแหล่งที่มาของข้อผิดพลาด:

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

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

11

ฉันจะไม่ลงคะแนนในสิ่งนี้ แต่ฉันถูกล่อลวงเพราะไม่เหมาะสมกับเกณฑ์ มันควรจะอนุญาตให้ "โปรแกรมเมอร์โดยเฉลี่ยส่งออกฟีเจอร์" ด้วยการนับบั๊กน้อยที่สุด แต่โปรแกรมเมอร์โดยเฉลี่ยที่จะทำให้มันโผงผางไม่สามารถทำให้หัวหรือก้อยของ Haskell ในตอนแรก

— Mason Wheeler

5

จุดที่ดีมากมาย แต่ในขณะที่การลบข้อผิดพลาดบางประเภท (ผลข้างเคียงที่ไม่ได้ตั้งใจการแปลงประเภทที่ไม่คาดคิด) Haskell เพิ่มข้อผิดพลาดคลาสใหม่ทั้งหมด: การรั่วไหลของพื้นที่ (นอกจากนี้แม้จะไม่มีใครnullมีundefinedซึ่งเป็นสมาชิกของทุกประเภท.)

— j_random_hacker

5

@Mason: ถ้าคุณไม่ได้เขียนในนั้นคุณจะไม่สามารถมีข้อบกพร่อง int มัน :)

— ไมเคิล K

2

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

— Benjol

6

@ ช่างก่ออิฐ "โปรแกรมเมอร์เฉลี่ย" คืออะไรกันแน่? คำถามเริ่มต้นด้วย "ภาษาการเขียนโปรแกรมอะไร ... " ไม่ใช่ "ซึ่งอยู่ในกลุ่ม C, C ++ และ java ... ";)

— Agos

18

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

แทบจะทำซ้ำไม่ได้
สามารถบอบบางมาก

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

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

แก้ไข: ใน Java Executorsจัดการส่วนที่ยากมากขึ้น คุณต้องทำให้แต่ละงานสอดคล้องกับCallableอินเตอร์เฟส

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

5

++ เงื่อนไขการแข่งขัน คุณสามารถพูดได้อีกครั้ง

— Mike Dunlavey

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

— David Thornley

แล้ว Erlang ล่ะ?

— Malfist

@ มัลลิสต์ฉันไม่รู้เกี่ยวกับ Erlang เพียงพอที่จะตอบคำถามนั้น บางทีคุณควรเปิดคำถามหากคุณต้องการรู้จริง ๆ ?

2

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

— Malfist

13

Ada ได้รับการออกแบบให้มากที่สุดเท่าที่จะเป็นไปได้ในการคอมไพล์เวลามากกว่าเวลาทำงาน สิ่งนี้หมายความว่ามันมักจะใช้เวลาประมาณ 10x ในการรับโปรแกรมใน Ada เพื่อคอมไพล์มากกว่าที่เทียบเท่าใน Java กล่าว แต่เมื่อมันรวบรวมคุณจะมั่นใจมากขึ้นว่าคลาสของบั๊กทั้งหมดจะไม่ปรากฏตัวเมื่อโปรแกรม วิ่ง.

— มาร์คพิมพ์
แหล่งที่มา

7

+1 สำหรับการสังเกตอย่างถูกต้องว่า Ada จับสิ่งต่าง ๆ ในคอมไพเลอร์ที่ภาษาอื่นไม่สนใจ -1 สำหรับการยืนยันว่านี่หมายความว่าใช้เวลานานขึ้น 10 เท่าในการรวบรวมโปรแกรม Ada Ada ให้รางวัลโปรแกรมเมอร์ที่ออกแบบ !!! รหัสของเขาที่คิดว่า !!! เกี่ยวกับสิ่งที่เขาทำก่อนที่เขาจะเริ่มพิมพ์อย่างบ้าคลั่ง ประสบการณ์ส่วนตัวของฉันในการเขียนโปรแกรมการผลิตใน Ada สำหรับงานด้านการป้องกันคือมันไม่ได้ใช้เวลานานกว่าจะได้รหัส Ada เพื่อคอมไพล์มากกว่าที่ใช้ C / C ++ หรือ FORTRAN แต่รหัส Ada มีปัญหาน้อยลงอย่างมากในภายหลัง Pratt & Whitney สังเกตเห็นบางสิ่งที่คล้ายกัน

— John R. Strohm

1

@ john r strohm จากสิ่งที่ฉันเข้าใจเขาไม่ได้พูดถึงเวลาที่คอมไพเลอร์จะคอมไพล์โค้ด แต่ถึงเวลาที่จะทำให้คอมไพล์โค้ดได้

— Malfist

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

— ไมเคิลชอว์

@Poleole หากเรือสามารถตั้งชื่อตามผู้หญิงได้ (ยกเว้นผู้ให้บริการในสหรัฐอเมริกา) ก็สามารถใช้ภาษาโปรแกรมได้เช่นกัน ค่อนข้างมีชื่อ "Ada" มากกว่า "USS Ronald Reagan" :)

1

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

— James Adam

7

คำจำกัดความแรก: ข้อผิดพลาดที่หายากอย่างที่ฉันเข้าใจเป็นข้อผิดพลาดที่สามารถทำซ้ำได้ แต่สาเหตุหายาก

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

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

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

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

เมื่อพิจารณาทั้งหมดที่ฉันจะบอกว่า Java และ C # และภาษาอื่น ๆ อีกมากมายในโลก JVM และ. net มีความเหมาะสมที่จะหลีกเลี่ยงข้อผิดพลาดที่หายาก

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

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

— Frank Shearar

Frank: อย่างน้อยการล็อคนั้นง่ายพอที่ทุกคนสามารถทำได้โดยไม่ต้องใช้เวลาหลายวันหาว่า API ตัว

— ไหนที่

จากนั้นมีมุมมองว่าโซลูชันการทำงานพร้อมกันที่ "ง่ายพอที่ทุกคนสามารถทำได้" ก็เหมือนกับการให้โต๊ะเลื่อยแก่เด็กก่อนวัยเรียน

— David Thornley

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

— 281377

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

— Giorgio

7

เนื่องจาก Excel เป็น DSL ที่ใช้กันอย่างแพร่หลายฉันจะไปกับ Excel (ไม่รวม VBA แน่นอน)

มันเหมาะกับการเรียกเก็บเงิน:

ทำซ้ำได้ง่ายเสมอ (นี่คือสเปรดชีต - ไม่ทำงาน)
มันค่อนข้างง่ายที่จะหาข้อผิดพลาดเนื่องจากมันเป็น "การทำงาน" โดยสิ้นเชิง - เริ่มจากเซลล์ที่ผิดและติดตามการอ้างอิงทั้งหมด

— Scott Whitlock
แหล่งที่มา

สิ่งนี้อาจเป็นจริงตราบใดที่คุณไม่ได้เพิ่มบั๊กที่หาได้ง่าย

— mouviciel

+1 หน้าด้านเล็กน้อยตั้งแต่ Excel เป็นข้อมูลไม่ใช่ภาษา ทำให้ฉันหัวเราะได้ดี :)

— recursion.ninja

2

@awashburn - โอ้ฉันไม่รู้ ฉันคิดว่ามันมีคุณสมบัติเป็นภาษา แต่ละเซลล์คือ "ตัวแปร" ตัวแปรแต่ละตัวจะถูกกำหนดอย่างชัดเจนว่าเป็นตัวอักษร (เช่น123หรือABC) หรือฟังก์ชั่น ( =SUM(A2:A5)) จากนั้น Excel จะประเมินตัวแปรทั้งหมดเพื่อหาว่าคำสั่งใดในการแก้ปัญหาการพึ่งพาและอื่น ๆ มันไม่ใช่แค่ข้อมูล

— Scott Whitlock

2

ฉันเพิกถอนคำแถลงของฉันปรากฎว่า Excel กำลังทำให้สมบูรณ์ ... ฉันเรียนรู้บางสิ่งที่ไม่มั่นคง ...

— recursion.ninja

1

"... ต้นแบบที่แท้จริง [Lisp] ตระหนักว่าข้อมูลทั้งหมดเป็นรหัส" บางทีนี่อาจใช้กับ Excel เช่นกันอย่างน่าประหลาดใจ blogs.msdn.com/b/sriram/archive/2006/01/15/lisp-is-sin.aspx

— James Mishra

7

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

ฉันเชื่อว่ามีคุณสมบัติหลายภาษาที่มีผลต่อโอกาสในการเกิดข้อบกพร่อง:

การโต้ตอบ - ภาษาไดนามิกกับ REPLs กระตุ้นให้เกิดการโต้ตอบ / ทดลองกับโปรแกรมที่กำลังรันและรอบรหัส / การทดสอบที่น้อยลงมาก หากคุณเชื่อว่าการวนซ้ำเป็นวิธีที่ดีในการค้นหาวิธีแก้ปัญหาที่เรียบง่ายและตรวจจับ / กำจัดข้อผิดพลาดสิ่งนี้มีแนวโน้มที่จะสนับสนุนภาษาแบบโต้ตอบ
ความรวดเร็ว - ถ้ารหัสสั้นกว่าและมีความซับซ้อนน้อยลงในส่วนของหม้อไอน้ำ / ความผิดพลาดน้อยกว่าดังนั้นจึงง่ายต่อการดูข้อบกพร่อง / ข้อผิดพลาดเชิงตรรกะ
ความปลอดภัยของประเภท - การตรวจสอบเวลาที่คอมไพล์มากขึ้นข้อผิดพลาดที่มากขึ้นจะถูกรวบรวมโดยคอมไพเลอร์ดังนั้นโดยทั่วไปความปลอดภัยของประเภทนั้นเป็นสิ่งที่ดี อย่างไรก็ตามสิ่งเหล่านี้มักจะไม่พบข้อบกพร่อง - แม้ในภาษาแบบไดนามิกเต็มรูปแบบชนิดผิดในโครงสร้างข้อมูลมักจะทำให้เกิดข้อผิดพลาดรันไทม์ที่ชัดเจนมากและ TDD มักจะรับข้อผิดพลาดประเภทนี้
Immutability - บั๊กจำนวนมากเกิดจากปฏิกิริยาที่ซับซ้อนของสถานะที่ไม่แน่นอน ภาษาที่เน้นการเปลี่ยนแปลงไม่ได้ (Haskell, Clojure, Erlang) มีข้อได้เปรียบอย่างมากจากการเปลี่ยนแปลงความไม่แน่นอน
ฟังก์ชั่นการเขียนโปรแกรม - วิธีการทำงานเพื่อเขียนโค้ดมีแนวโน้มที่จะ "ถูกต้องพิสูจน์ได้" มากกว่าโค้ดเชิงวัตถุที่มีลำดับที่ซับซ้อนของเอฟเฟกต์ / การโต้ตอบ ประสบการณ์ของฉันคือ FP ช่วยหลีกเลี่ยงข้อผิดพลาดที่ยุ่งยาก - ฉันเชื่อว่ามีงานวิจัยทางวิชาการบางแห่งที่ฉันไม่สามารถหาได้ในขณะนี้
การสนับสนุนการเกิดพร้อมกัน - ปัญหาการเกิดขึ้นพร้อมกันนั้นยากต่อการตรวจจับและดีบักซึ่งเป็นสาเหตุที่สำคัญมาก สิ่งที่ต้องใช้การล็อคด้วยตนเองในที่สุดก็ถึงวาระที่จะล้มเหลว (และรวมถึงทุกวิธีการเชิงวัตถุเพื่อการทำงานพร้อมกัน) ภาษาที่ดีที่สุดที่ฉันรู้ในเรื่องนี้คือ Clojure - มันมีวิธีการที่ไม่เหมือนใครในการจัดการภาวะพร้อมกันที่รวมหน่วยความจำทรานแซคชันของซอฟต์แวร์เข้ากับโครงสร้างข้อมูลที่ไม่เปลี่ยนรูปแบบ ดูhttp://www.infoq.com/presentations/Value-Identity-State-Rich-Hickeyสำหรับข้อมูลเชิงลึกเพิ่มเติม

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

คนอย่างฉันที่เป็นผู้สนับสนุนการเขียนโปรแกรมแบบใช้ฟังก์ชันชื่นชมคำตอบนี้ การแสดงออกเป็นเพื่อนของคุณ

— Sridhar Sarnobat

1

คำตอบที่ดีที่สุด! ฉันคิดว่านี้ได้รับการสนับสนุนโดยทั้งสองต่อไปนี้การวิเคราะห์ความถี่ของข้อผิดพลาด: deliberate-software.com/safety-rank-part-2และmacbeth.cs.ucdavis.edu/lang_study.pdf พวกเขาทั้งคู่แสดงให้เห็นว่ายิ่งบริสุทธิ์ยิ่งทำงานได้มากขึ้นแสดงออกได้มากขึ้นและปลอดภัยยิ่งขึ้นภาษาก็ยิ่งมีข้อผิดพลาดน้อยลงเท่านั้น ในทำนองเดียวกันพวกเขาทั้งสองแสดงให้เห็นว่า Clojure และ Ruby หนีออกจากกฎความปลอดภัยซึ่งอาจบ่งบอกว่าการโต้ตอบนั้นมีผลกระทบเท่ากันตามที่คุณชี้ให้เห็น

— Didier A.

@DidierA น่าเสียดายที่ลิงก์ ucdavis เสีย (โดยไม่มีไฟล์เก็บถาวร wbm) - ฉันคิดว่าคุณได้รับจากหน้าของ Prem Devanbuซึ่งตอนนี้ชี้ไปที่ลิงก์ที่อัปเดตแล้ว: การศึกษาขนาดใหญ่ของภาษาการเขียนโปรแกรมและคุณภาพของรหัสใน Github

— icc97

5

ภาษาที่มีพลังน้อยกว่าก็คือตัวเลือกที่น้อยลงจะช่วยให้คุณถ่ายภาพเท้าของคุณเอง

ภาษาระดับสูงเช่น Java และ C # จะสร้างบั๊กน้อยกว่าภาษาระดับต่ำเช่น C ++

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

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

4

+1 สำหรับ "ภาษาที่มีพลังน้อยกว่านั้นคือตัวเลือกน้อยกว่าที่จะทำให้คุณยิงด้วยเท้าของคุณเอง"

— Michael K

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

— Jesse C. Slicer

6

ความปลอดภัยและพลังงานไม่ได้แปรผกผัน (ซึ่งเป็นสิ่งที่คุณคิด ;-) Haskell ยกตัวอย่างมีพลังมากและยังมีวิธียิงตัวเองน้อยมาก

— missingfaktor

3

หากภาษาอ่อนแอคุณเพียงแค่ต้องการเท้าที่ใหญ่กว่า

7

@missingfaktor นั่นเป็นเพราะมันเป็นผลข้างเคียงที่จะยิงตัวเองในเท้า

3

ในความเห็นของคุณว่าภาษาใดที่อนุญาตให้โปรแกรมเมอร์โดยเฉลี่ยให้คุณสมบัติการส่งออกที่มีข้อบกพร่องที่ยากต่อการค้นหาน้อยที่สุด?

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

การพิมพ์ที่รัดกุมและคอมไพเลอร์ที่เข้มงวดซึ่งตรวจจับข้อผิดพลาดทั่วไปจำนวนมาก
ไวยากรณ์ที่ใช้งานง่ายที่ไม่สนับสนุนข้อผิดพลาดทั่วไป ("The Bug's Last Bug" if (alert = RED) {LaunchNukes;}จะไม่รวบรวมเช่น)
รูปแบบวัตถุที่ออกแบบมาอย่างดีเพื่อลดข้อผิดพลาดทั่วไปของ C ++ OOP
การตรวจสอบขอบเขตและการตรวจสอบช่วงที่มีอยู่ในภาษาช่วยลดโอกาสในการเกิดปัญหาด้านความปลอดภัยได้อย่างมาก
อาจเป็นคอมไพเลอร์ที่เร็วที่สุดที่มนุษย์รู้จักซึ่งจะเพิ่มประสิทธิภาพการทำงานของคุณและทำให้มันยากที่จะสูญเสียความคิดในขณะที่รอการสร้าง
ดีบักเกอร์ Visual Studio ดีบักเกอร์อยากเป็นเหมือนเมื่อโตขึ้น
การติดตามการรั่วไหลถูกสร้างขึ้นในตัวจัดการหน่วยความจำโดยตรงทำให้การค้นหาและแก้ไขการรั่วไหลของหน่วยความจำเล็กน้อย
ไลบรารี่มาตรฐานขนาดใหญ่สำหรับผู้ใหญ่ที่มอบวิธีการที่สร้างไว้ล่วงหน้าและทดสอบล่วงหน้าเพื่อให้งานทั่วไปสำเร็จโดยไม่ต้องสร้างการใช้งานของคุณเอง
จัดส่งด้วยเครื่องมือที่มีประโยชน์เช่นระบบการบันทึกที่มีประสิทธิภาพและผู้สร้างโปรไฟล์เพื่อให้การติดตามปัญหาง่ายขึ้น
การสนับสนุนจากชุมชนที่แข็งแกร่งสำหรับปัญหาที่พบบ่อยที่ไม่อยู่ในห้องสมุดมาตรฐานรวมถึงบุคคลที่สามห้องสมุดที่มีประสิทธิภาพการทำงานพร้อมกัน

— Mason Wheeler
แหล่งที่มา

ฉันเป็นนักจัดรายการ Delphi จากทางกลับ แต่มันก็ออกไปจากมันเป็นรากปาสกาลเมื่อมันอนุญาตให้ฉันพิมพ์สิ่งอื่นใด la la C / C ++:var I: Integer; Pointer(I)^ := $00;

— Jesse C. เครื่องตัด

1

@ เจสซี: บางที แต่ฉันเห็นว่าเป็นสัมปทานที่จำเป็นในการปฏิบัตินิยม Kernighan ทำคะแนนได้ดีมากเมื่อเขาเขียนว่าทำไม Pascal ไม่ใช่ภาษาโปรแกรมที่ฉันโปรดปราน Typecasts จำเป็นต้องทำสิ่งที่สำคัญในระดับต่ำให้เสร็จ แต่จุดแข็งอย่างหนึ่งของ Delphi คือวิธีที่ห้องสมุดของมันห่อหุ้มรายละเอียดในระดับต่ำและใช้ประโยชน์จากตัวชี้ที่ไม่ปลอดภัยและตัวพิมพ์ที่ไม่ปลอดภัยซึ่งไม่จำเป็น

— Mason Wheeler

ฉันไม่เห็นด้วยว่ามันอาจจำเป็น - แต่การอ้างว่าการพิมพ์ที่แข็งแกร่งนั้นค่อนข้างถูกทำให้ไร้ผล ปาสคาลดั้งเดิมไม่อนุญาตให้ใช้ shenanigans ดังกล่าวและดังนั้นจึงถูกพิมพ์อย่างยิ่ง แต่ฉันจะไม่ไปไกลที่จะเรียก Delphi ที่พิมพ์อย่างอ่อน - มันเป็นประเภทของ "ปานกลาง - ดีพิมพ์"

— Jesse C. Slicer

1

@Jesse: Pascal รุ่น Wirth ดั้งเดิมไม่อนุญาตให้มีการบันทึกที่หลากหลายใช่หรือไม่ IIRC ในที่สุดพวกเขาก็ถูกใช้โดยทั่วไปเพื่อล้มล้างการพิมพ์ที่แข็งแกร่งที่ Borland และคนอื่น ๆ ตัดสินใจที่จะใส่ typecasts เพื่อทำให้มันง่ายขึ้นเพราะทุกคนกำลังทำมันอยู่ดี

— Mason Wheeler

en.wikipedia.org/wiki/Pascal_(programming_language)#Divisionsและen.wikipedia.org/wiki/Pascal_(programming_language)#Criticismเช่นเดียวกับpascal-central.com/ppl/chapter3.htmlชี้ให้เห็นว่ามันเป็นส่วนหนึ่งของ มาตรฐานแรกในปี 1983 ฉันเห็นการอ้างอิงของ Wirth ซึ่งดูเหมือนจะถึงปี 1974 ดังนั้นฉันจึงบอกว่าใช่แล้ว ฉันคิดว่าส่วนที่มีปัญหาคือการยอมให้มันถูกโค่นล้ม (เช่นเขตข้อมูลตัวแปรที่ใช้หน่วยความจำเดียวกันเช่นสหภาพใน C) ถ้าพวกมันถูกใช้เป็นกลไกในการกำหนดขอบเขตและเลย์เอาต์ของหน่วยความจำนั้นมีไว้สำหรับชุดซูเปอร์

— Jesse C. Slicer

2

สิ่งหนึ่งที่ต้องคำนึงถึงก็คือเวลาในการหมุน

ในช่วงห้าปีที่ผ่านมาฉันได้พัฒนาเว็บแอปพลิเคชั่นเป็นหลักใน java (JSF, Seam และอื่น ๆ ) เมื่อเร็ว ๆ นี้ฉันได้งานใหม่และเรากำลังใช้ Perl (กับ Catalyst และ Moose)

ฉันเป็นวิธีที่มีประสิทธิภาพมากขึ้นใน Perl กว่าที่ฉันเป็นใน Java

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

ฉันเดาจำนวนข้อบกพร่องในรหัส Perl ของฉันมากกว่าหรือน้อยกว่าจำนวนข้อบกพร่องในรหัส Java ของฉันก็อาจจะสูงขึ้น แต่ฉันค้นหาและง่ายขึ้นและเร็วขึ้นในการค้นหาและแก้ไขข้อบกพร่องเหล่านี้

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

1

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

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

1

"หลีกเลี่ยงการสึกหรอของฮาร์ดแวร์ตามอายุ" ... ?

— j_random_hacker

ฉันได้อ่านว่าระบบปฏิบัติการ Unix บางเครื่องที่ทำงานบนเครื่องที่มีภารกิจสำคัญตรวจสอบสุขภาพของ CPU, RAM และฮาร์ดแวร์อื่น ๆ serverfault.com/questions/56192/…พูดถึงสิ่งนี้ในเชิงลึก หากบางบรรทัดในโมดูล RAM มีข้อผิดพลาดเมื่อเวลาผ่านไปโมดูลที่ผิดพลาดเหล่านั้นจะไม่ถูกใช้โดยระบบปฏิบัติการและจะไม่รายงานในหน่วยความจำกายภาพทั้งหมดที่มีให้ สิ่งต่าง ๆ สามารถทำได้บนฮาร์ดแวร์อื่นเช่นกัน

— vpit3833

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

— j_random_hacker

1

ฉันบอกว่ามันหมายถึงว่าโปรแกรมเพียงอย่างเดียวอาจไม่ใช่แหล่งที่มาของข้อบกพร่องมันอาจเป็นฮาร์ดแวร์หรือปัจจัยภายนอกอื่น ๆ เช่นกัน

— vpit3833

1

แทนที่จะพูดเกี่ยวกับภาษาสิ่งที่พูดถึงคุณสมบัติภาษา

java บังคับให้คุณคิดถึงข้อยกเว้น (พ่น ... ) และคุณจะต้อง publisch หรือจัดการข้อยกเว้นเหล่านี้ ความจริงนั้นป้องกันฉันจากการลืมสถานการณ์ข้อผิดพลาดหรือฉันใช้ข้อยกเว้นเพิ่มเติมที่มาจาก SystemException ที่ไม่ต้องการการจัดการนี้หรือไม่?
สิ่งที่เกี่ยวกับ "การออกแบบโดยสัญญา" (http://en.wikipedia.org/wiki/Design_by_contract) ที่บังคับให้ฉันต้องคิดก่อนและหลัง ฉันได้อ่านแล้วว่าเป็นไปได้ด้วย c # -4.0

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