การศึกษาภาษาแบบไดนามิกกับแบบคงที่ vs [ปิด]


69

มีการศึกษาเกี่ยวกับประสิทธิภาพของภาษาที่พิมพ์แบบคงที่และแบบไดนามิกหรือไม่?

โดยเฉพาะอย่างยิ่ง:

  • การวัดผลผลิตโปรแกรมเมอร์
  • อัตราข้อบกพร่อง

รวมถึงผลกระทบของการทดสอบหน่วยหรือไม่

ฉันเคยเห็นการถกเถียงกันถึงข้อดีของทั้งสองด้านแล้ว แต่ฉันก็สงสัยว่าใครมีการศึกษาบ้างไหม


8
@bigown ก็ไม่ได้ดูเหมือนกับผมว่าปัญหาของการผลิตและข้อบกพร่องที่เกี่ยวข้องกับทฤษฎีวิทยาศาสตร์คอมพิวเตอร์
วินสตัน Ewert

2
@ Winston: การศึกษาปัญหาแบบนี้มันเป็นงานของนักวิทยาศาสตร์คอมพิวเตอร์ไม่ใช่โปรแกรมเมอร์
Maniero

9
@ ใหญ่, ใช่มันเป็นปัญหาวิทยาการคอมพิวเตอร์ แต่มันไม่ได้เป็นปัญหาทฤษฎีวิทยาศาสตร์คอมพิวเตอร์ ทฤษฎี CS เกี่ยวข้องกับสิ่งที่เราสามารถพิสูจน์ทางคณิตศาสตร์เกี่ยวกับโปรแกรมและการคำนวณ ประเด็นการเพิ่มผลผลิตของโปรแกรมเมอร์ไม่ใช่คำถามเชิงทฤษฎี มีการพูดคุยเกี่ยวกับการพิมพ์แบบไดนามิกทั้งที่นี่และใน stackoverflow ไม่มีใครอยู่ในห้องเก็บของ
Winston Ewert

8
คำถามนั้นสมบูรณ์แบบในหัวข้อ คำถามนี้กล่าวถึงหนึ่งในคุณสมบัติที่สำคัญที่สุดของเครื่องมือที่เราใช้ในการเขียนโปรแกรม
Frank Shearar

4
@ Winston: ระบบการพิมพ์มีอยู่ในทฤษฎี CS แต่การศึกษาเชิงปฏิบัติไม่ได้
David Thornley

คำตอบ:


42

บางคนแนะนำให้อ่าน:

ไม่เกี่ยวกับการพิมพ์คงที่ แต่เกี่ยวข้อง:

บทความหรือบทความที่น่าสนใจเกี่ยวกับเรื่องหรือการวิเคราะห์แบบคงที่ของโปรแกรมโดยทั่วไป:

และสำหรับคนที่จะสงสัยว่าสิ่งนี้เป็นเรื่องเกี่ยวกับ:

อย่างไรก็ตามฉันสงสัยว่าสิ่งเหล่านี้จะให้คำตอบโดยตรงกับคุณเนื่องจากพวกเขาไม่ได้ทำการศึกษาที่คุณกำลังมองหา พวกเขาจะอ่านที่น่าสนใจ

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

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


การค้นหาบั๊กนั้น - ส่วนใหญ่เป็นเพราะชื่อตัวแปรสะกดผิดหรือชื่อเมธอดหรือบางที่อยู่ระหว่างนั้น? (ฉันเกลียดการประกาศตัวแปรโดยนัยด้วยเหตุผลนี้: ใน Smalltalk คุณจะประกาศตัวแปรทั้งหมดที่ด้านบนดังนั้นคุณจะรู้ได้ทันทีว่าคุณพิมพ์ชื่อตัวแปรผิด (บางครั้งชื่อเมธอดจะถูกจับด้วยเช่นกันถ้าชื่อเมธอดไม่เคย ถูกนำมาใช้ในภาพก่อน)))
Frank Shearar

ต้องบอกว่ามันขึ้นอยู่กับภาษาของคุณ - Smalltalk มีเครื่องมือที่ยอดเยี่ยมรวมถึง Refactoring Browser ที่ Eclipse มี (ฉันบอก) ยังไม่ทันได้
Frank Shearar

@ Frank Shearar ตั้งแต่ฉันเริ่มต้นด้วย Ruby (มาจาก Java) ฉันรู้ว่า @ haylem ที่พูดอาจไม่เหมาะกับ Smalltalk มนต์ของฉันไม่เกี่ยวกับการปรับโครงสร้างอัตโนมัติใหม่เป็นไปไม่ได้ในภาษาที่พิมพ์แบบไดนามิก ฉันเห็นด้วยอย่างยิ่งกับส่วน "ส่วนตัว" ของเฮย์เล็ม .... ไม่สนใจ SmallTalk แน่นอน :) นี่ยุติธรรมพอใช้ตั้งแต่ SmallTalk ในขณะที่ยังไม่ตายแน่นอนไม่สนุกกับความนิยมที่ Python หรือ Ruby มี (ตอนนี้ในเดือนตุลาคม 2010 )
Dan Rosenstark

3
@Haylem โดยส่วนตัวฉันขอขอบคุณที่ทำให้ฉันรู้สึกว่าฉันไม่ใช่คนเดียวในโลกที่ทำงานในภาษาแบบไดนามิก แต่เมื่อได้รับเลือกหลายครั้งเลือกภาษาที่พิมพ์แบบคงที่ (กรณีเดียวกัน Java กับ JRuby หรือ Groovy)
Dan Rosenstark

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

19

เมื่อวานนี้ฉันเพิ่งพบการศึกษานี้: การทดสอบหน่วยไม่เพียงพอ คุณต้องพิมพ์แบบคงที่เช่นกัน

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

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

การแปลเป็น Haskell เปิดเผยชุดของข้อผิดพลาดที่เกี่ยวข้องกับประเภทของตัวแปร: ข้อผิดพลาดที่หน่วยทดสอบไม่พบ


4
ความจริงอึดอัดในการพิมพ์แบบไดนามิก
Den

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

4
ฉันตอบกลับโพสต์ในลิงค์นี้ใน Reddit ฉันไม่คิดว่าข้อสรุปที่ได้จากกระดาษนั้นสมเหตุสมผล
Veedrac

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

10
  • เชื่อมโยงไปยังการอภิปรายของกระดาษ ACM " การทดลองเกี่ยวกับระบบประเภทคงที่และแบบไดนามิก " (2010) โดยบทความ Stephan Hanenberg (อ้างอิงโดย Lorin Hochstein ในบทความก่อนหน้า)
  • สรุป: ผลผลิตเพื่อคุณภาพใกล้เคียงกันสูงกว่าในภาษาไดนามิก
  • ปัญหาอคติ / ความถูกต้องที่อาจเกิดขึ้น: วิชาทดลองเป็นนักเรียนทุกคน นอกจากนี้ยังมีข้อ จำกัด ของงานเขียนโปรแกรมที่หลากหลาย (วิชาถูกขอให้ใช้เครื่องสแกนและโปรแกรมแยกวิเคราะห์)
  • กระดาษ ACM " ภาษาการเขียนโปรแกรมมีผลกระทบต่อผลผลิตหรือไม่ " (2007) โดย Delorey, Knudson และ Chun
  • สรุป: JavaScript, Tcl, Perl มีประสิทธิผลมากกว่า C # C ++ และ Java Python และ PHP อยู่ตรงกลาง
  • โอกาสเกิดอคติ / ความถูกต้องที่อาจเกิดขึ้น: ไม่มีการวัดคุณภาพ (เช่นข้อบกพร่องที่ค้นพบภายหลังการเผยแพร่) ไม่มีการวัดความน่าเชื่อถือ (ซอฟต์แวร์ที่เขียนด้วยภาษาที่พิมพ์คงที่เชื่อถือได้มากกว่านี้หรือไม่) ตัวอย่างความลำเอียง - โครงการทั้งหมดถูกเปิดจากที่เก็บ CVS แบบโอเพ่นซอร์ส นอกจากนี้ไม่มีความแตกต่างระหว่างภาษาที่อ่อนแอและพิมพ์อย่างรุนแรง (เช่นตัวชี้)
  • วิทยานิพนธ์ " การศึกษาเชิงประจักษ์ของการเพิ่มผลิตภาพและคุณภาพซอฟต์แวร์ " (2008) โดย Michael F. Siok
  • สรุป: การเลือกภาษาการเขียนโปรแกรมไม่มีผลต่อประสิทธิภาพหรือคุณภาพอย่างมีนัยสำคัญ อย่างไรก็ตามจะส่งผลกระทบต่อต้นทุนแรงงานและ "คุณภาพภายในผลงานซอฟต์แวร์โดยรวมของโครงการ"
  • ปัญหาอคติ / ความถูกต้องที่อาจเกิดขึ้น: จำกัด เฉพาะโดเมน avionics ภาษาการเขียนโปรแกรมอาจถูกพิมพ์แบบคงที่ทั้งหมด ฉันไม่ได้อ่านวิทยานิพนธ์ดังนั้นฉันไม่สามารถประเมินความแม่นยำของมันได้
    ความคิดเห็นของฉัน. แม้ว่าจะมีหลักฐานที่อ่อนแอว่าภาษาที่พิมพ์แบบไดนามิกนั้นมีประสิทธิผลมากกว่า แต่ก็ไม่ได้ข้อสรุป (1) มีหลายปัจจัยที่ไม่ได้ถูกควบคุม (2) มีการศึกษาน้อยเกินไป (3) มีการอภิปรายเพียงเล็กน้อยหรือไม่มีเลยเกี่ยวกับสิ่งที่ถือเป็นวิธีการทดสอบที่เหมาะสม

6

นี่คือจุดเริ่มต้น:

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


5
สำหรับคนที่ไม่ใช่ IEEE สรุปพื้นฐานคืออะไร
Frank Shearar

1
@ Frank Shearar ข้อสรุปที่พวกเขาวาดคือภาษาการเขียนโปรแกรมส่งผลกระทบต่อผลผลิต พวกเขากำลังวัดจำนวนบรรทัดของรหัสต่อโปรแกรมเมอร์ต่อภาษาต่อปีฉันไม่แน่ใจว่านั่นเป็นการวัดประสิทธิภาพที่ดี
Winston Ewert

3
@ Winston: นั่นเป็นตัวชี้วัดที่มีข้อบกพร่องอย่างแน่นอน คุณจะพบว่าภาษาโคบอลเป็นภาษาที่มีประสิทธิผลมากโดยใช้บรรทัดมากมายในการทำสิ่งที่มีประโยชน์ แต่มันค่อนข้างง่ายต่อการเขียน
David Thornley

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

ฉันเห็นด้วยกับที่ แต่มันก็ไม่ตอบคำถามเดิมของฉัน
Winston Ewert

1

ฉันพบภาษาแบบคงที่และแบบไดนามิก: การทบทวนวรรณกรรมซึ่งแสดงรายการการศึกษาบางเรื่องเกี่ยวกับเรื่องนี้และให้บทสรุปที่ดีเกี่ยวกับการศึกษาแต่ละครั้ง

นี่คือบทสรุปผู้บริหาร:

จากการทดลองที่ควบคุมแล้วมีเพียงสามชิ้นเท่านั้นที่แสดงผลที่มีขนาดใหญ่พอที่จะมีความสำคัญในทางปฏิบัติ การศึกษา Prechelt เปรียบเทียบ C, C ++, Java, Perl, Python, Rexx และ Tcl; การศึกษา Endrikat เปรียบเทียบ Java และ Dart; และการทดสอบของ Cooley กับ VHDL และ Verilog แต่น่าเสียดายที่พวกเขามีปัญหาที่ทำให้ยากที่จะสรุปข้อสรุปที่แข็งแกร่งจริงๆ

ในการศึกษา Prechelt ประชากรมีความแตกต่างระหว่างภาษาไดนามิกและภาษาที่พิมพ์และเงื่อนไขสำหรับภารกิจก็แตกต่างกันเช่นกัน มีการศึกษาติดตามผลที่แสดงให้เห็นปัญหาโดยการเชิญ Lispers เพื่อหาวิธีการแก้ปัญหาของพวกเขาเองซึ่งเกี่ยวข้องกับการเปรียบเทียบคนอย่าง Darius Bacon กับการสุ่มแบบสุ่ม การติดตามการติดตามอย่างแท้จริงเกี่ยวข้องกับการเปรียบเทียบรหัสจาก Peter Norvig กับรหัสจากนักศึกษาวิทยาลัยแบบสุ่ม

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

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

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

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

ในฐานะผู้ใช้ฉันคิดว่ามันสะดวกเมื่อคอมไพเลอร์ของฉันให้ฉันข้อผิดพลาดก่อนที่ฉันจะเรียกใช้เครื่องมือวิเคราะห์แบบคงที่แยกจากกัน

ฉันพบกรณีศึกษาของ 0install (ที่เปรียบเทียบภาษาต่าง ๆ กับ Python และตั้งรกรากใน Ocaml) เป็นสิ่งที่น่าสนใจมากที่ฉันวิ่งข้าม แต่มันเป็นเรื่องส่วนตัวที่ทุกคนจะตีความแตกต่างกันซึ่งคุณสามารถมองเห็นได้ด้วยการมอง .

เหมาะกับความประทับใจที่ฉันมี (ในมุมเล็ก ๆ ของโลก, ACL2, Isabelle / HOL และ PVS เป็นเครื่องพิสูจน์ที่ใช้กันมากที่สุดและทำให้รู้สึกว่าผู้คนจะชอบระบบอัตโนมัติมากขึ้นเมื่อแก้ปัญหาในอุตสาหกรรม) แต่นั่นก็คือ อัตนัยยัง

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

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

การละเว้นการศึกษาที่น่าสนใจบางอย่างเป็นการศึกษาที่ครอบคลุมโดยใช้โปรแกรมเมอร์ที่มีประสบการณ์การศึกษาเดี่ยวที่มีประชากรจำนวนมากของโปรแกรมเมอร์“ ดี” หรือ“ ไม่ดี” มองสิ่งใดก็ตามที่เข้าใกล้โครงการที่สำคัญ (ในสถานที่ที่ฉันเคยทำงานโครงการสามเดือน ได้รับการพิจารณาว่ามีขนาดเล็ก แต่นั่นเป็นคำสั่งที่มีขนาดใหญ่กว่าโครงการใด ๆ ที่ใช้ในการศึกษาแบบควบคุม) โดยใช้ภาษาที่พิมพ์แบบ "ทันสมัย" แบบคงที่โดยใช้การพิมพ์ทีละส่วน / ทางเลือกโดยใช้ IDE หลักกระแสหลัก (เช่น VS และ Eclipse) (เช่น LightTable) โดยใช้เครื่องมือแก้ไขโรงเรียนเก่า (เช่น Emacs และ vim) ทำการบำรุงรักษาบนโค้ดเบสที่ไม่สำคัญการบำรุงรักษาสิ่งที่คล้ายกับสภาพแวดล้อมจริงทำการบำรุงรักษาบนโค้ดเบสที่คุณคุ้นเคยอยู่แล้ว ฯลฯ

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


0

ฉันไม่คิดว่าการพิมพ์แบบคงที่และแบบไดนามิกเป็นคำถามจริง

ฉันคิดว่ามีสองพารามิเตอร์ที่ควรมาก่อน:

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

หากคุณคุ้นเคยกับภาษาคุณจะเขียนโค้ดและคุณจะสามารถติดตามบั๊กได้อย่างง่ายดาย

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

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


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

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

แต่จนกว่าจะมีใครบางคนทำการศึกษาจริงที่พิจารณาคำถามนี้ - ไม่ว่าจะเป็นวิธีการเครื่องมือมีผลกระทบมากกว่าภาษาเกี่ยวกับอัตราข้อบกพร่องการเพิ่มผลผลิต - เราเพิ่งจบการเปรียบเทียบเกร็ดเล็กเกร็ดน้อย
Frank Shearar

0

นี่คือบางส่วน:

  • Stefan Hanenberg 2010 การทดลองเกี่ยวกับระบบชนิดคงที่และแบบไดนามิก: สงสัยเกี่ยวกับผลกระทบเชิงบวกของระบบชนิดคงที่ในเวลาการพัฒนา ในการดำเนินการประชุมนานาชาติ ACM เกี่ยวกับภาษาและแอปพลิเคชันระบบเชิงวัตถุ (OOPSLA '10) ACM, New York, NY, USA, 22-35 DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, "ภาษาการเขียนโปรแกรมมีผลกระทบต่อผลผลิตหรือไม่กรณีศึกษาการใช้ข้อมูลจากโครงการโอเพนซอร์ซ" floss, pp.8, การประชุมเชิงปฏิบัติการระดับนานาชาติครั้งแรกในแนวโน้มการวิจัยและพัฒนาของ FLOSS '07: ICSE Workshops 2007), 2007

  • เดลี, ม.; Sazawal, V. , Foster, J .: งานที่กำลังดำเนินการ: การศึกษาเชิงประจักษ์ของการพิมพ์ดีดแบบคงที่ใน Ruby, การประชุมเชิงปฏิบัติการเรื่องการประเมินผลและการใช้งานภาษาโปรแกรมและเครื่องมือ (PLATEAU) ที่ ON-WARD 2009

  • Lutz Prechelt และ Walter F. Tichy 1998. การทดลองควบคุมเพื่อประเมินประโยชน์ของการตรวจสอบประเภทอาร์กิวเมนต์ของขั้นตอน IEEE Trans Softw เอ็ง 24, 4 (เมษายน 2541), 302-312 DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.