Các nghiên cứu ngôn ngữ gõ động và tĩnh [đóng]


69

Có tồn tại các nghiên cứu được thực hiện về hiệu quả của các ngôn ngữ gõ tĩnh và động?

Đặc biệt:

  • Đo lường năng suất lập trình viên
  • Tỷ lệ khuyết tật

Cũng bao gồm các tác động của việc kiểm tra đơn vị có được sử dụng hay không.

Tôi đã thấy rất nhiều cuộc thảo luận về giá trị của cả hai bên nhưng tôi tự hỏi liệu có ai đã thực hiện một nghiên cứu về nó không.


8
@bigown, đối với tôi, dường như các vấn đề về năng suất và khiếm khuyết liên quan đến lý thuyết khoa học máy tính
Winston Ewert

2
@Winston: Nghiên cứu loại vấn đề này là công việc của các nhà khoa học máy tính, không phải lập trình viên.
Maniero

9
@bigown, vâng, nó là một vấn đề khoa học máy tính nhưng nó không phải là vấn đề lý thuyết khoa học máy tính. Lý thuyết CS về cơ bản liên quan đến những gì chúng ta có thể chứng minh về mặt toán học về các chương trình và máy tính. Các vấn đề về năng suất lập trình không phải là câu hỏi lý thuyết cs. Đã có các cuộc thảo luận về cách gõ động cả ở đây và trên stackoverflow. Không có ai trên cstheory.
Winston Ewert

8
Câu hỏi hoàn hảo về chủ đề. Câu hỏi này thảo luận về một trong những tính chất quan trọng nhất của các công cụ chúng ta sử dụng để lập trình.
Frank Shearar

4
@Winston: Các hệ thống đánh máy thuộc về lý thuyết CS, nhưng các nghiên cứu thực tế thì không.
David Thornley

Câu trả lời:


42

Một số gợi ý đọc:

Không chính xác về gõ tĩnh, nhưng liên quan:

Một số bài viết hoặc bài tiểu luận thú vị về chủ đề hoặc phân tích tĩnh các chương trình nói chung:

Và đối với những người sẽ tự hỏi điều này là gì:

Tuy nhiên, tôi nghi ngờ bất kỳ câu hỏi nào trong số này cung cấp cho bạn câu trả lời trực tiếp, vì chúng không thực hiện chính xác nghiên cứu mà bạn đang tìm kiếm. Họ sẽ được đọc thú vị mặc dù.

Cá nhân, Tôi chắc chắn xem xét rằng gõ tĩnh trên gõ động tạo điều kiện phát hiện lỗi. Tôi dành quá nhiều kiểu tìm kiếm lỗi chính tả và những lỗi nhỏ như thế này vào JavaScript hoặc thậm chí mã Ruby. Và khi nói đến việc Dynamic Typing giúp bạn tăng năng suất, tôi nghĩ rằng điều đó chủ yếu đến từ công cụ. Nếu các ngôn ngữ được nhập tĩnh có các công cụ phù hợp để cho phép biên dịch lại nền và cung cấp giao diện REPL, thì bạn sẽ nhận được lợi ích của cả hai thế giới. Scala cung cấp ví dụ này, giúp bạn dễ dàng học và tạo nguyên mẫu trong bảng điều khiển tương tác, nhưng mang lại cho bạn những lợi ích của việc gõ tĩnh (và của một hệ thống loại mạnh hơn nhiều ngôn ngữ khác, ngôn ngữ ML sang một bên). Tương tự, tôi không nghĩ mình bị giảm năng suất khi sử dụng Java hoặc C ++ (vì gõ tĩnh), miễn là tôi sử dụng một IDE giúp tôi làm theo. Khi tôi trở lại mã hóa chỉ với các cấu hình đơn giản (trình soạn thảo + trình biên dịch / trình thông dịch), thì nó cảm thấy các ngôn ngữ động và cồng kềnh hơn có vẻ dễ sử dụng hơn. Nhưng bạn vẫn săn lùng bọ. Tôi đoán mọi người sẽ nói rằng vấn đề công cụ là một đối số có thể đảo ngược, vì nếu công cụ tốt hơn cho các ngôn ngữ động, thì hầu hết các lỗi và lỗi chính tả sẽ được chỉ ra vào thời điểm mã hóa, nhưng theo tôi thì đó là lỗi của hệ thống. Tuy nhiên, tôi thường tạo nguyên mẫu trong JRuby và sẽ viết mã bằng Java sau hầu hết những điều tôi làm. như thể công cụ tốt hơn cho các ngôn ngữ động, thì theo tôi, hầu hết các lỗi và lỗi chính tả sẽ được chỉ ra vào thời điểm mã hóa, nhưng theo tôi thì điều đó phản ánh lỗ hổng trong hệ thống. Tuy nhiên, tôi thường tạo nguyên mẫu trong JRuby và sẽ viết mã bằng Java sau hầu hết những điều tôi làm. như thể công cụ tốt hơn cho các ngôn ngữ động, thì theo tôi, hầu hết các lỗi và lỗi chính tả sẽ được chỉ ra vào thời điểm mã hóa, nhưng theo tôi thì điều đó phản ánh lỗ hổng trong hệ thống. Tuy nhiên, tôi thường tạo nguyên mẫu trong JRuby và sẽ viết mã bằng Java sau hầu hết những điều tôi làm.

CẢNH BÁO: Một số liên kết này không đáng tin cậy và một số liên kết thông qua các cổng của các xã hội điện toán khác nhau bằng cách sử dụng truy cập dựa trên phí cho các thành viên. Xin lỗi về điều đó, tôi đã cố gắng tìm nhiều liên kết cho mỗi liên kết này nhưng nó không tốt như tôi muốn.


Phát hiện lỗi đó - chủ yếu là do tên biến sai chính tả, hoặc tên phương thức hoặc ở đâu đó ở giữa? (Tôi không ưa khai báo biến tiềm ẩn cho chính xác lý do này: trong Smalltalk, bạn khai báo tất cả các biến của bạn ở phía trên, vì vậy bạn biết ngay khi bạn đã gõ sai một tên biến (Phương pháp tên lỗi chính tả đôi khi được đánh bắt quá, nếu tên phương pháp là không bao giờ. đã được sử dụng trong hình ảnh trước đó.))
Frank Shearar

Về công cụ, tôi phải nói rằng nó phụ thuộc vào ngôn ngữ của bạn - Smalltalk có các công cụ tuyệt vời, bao gồm cả Trình duyệt tái cấu trúc mà Eclipse (tôi đã nói) chưa bắt kịp.
Frank Shearar

@Frank Shearar, kể từ khi tôi bắt đầu với Ruby (đến từ Java), tôi đã nhận ra rằng những gì @ haylem nói có lẽ không áp dụng cho Smalltalk. Thần chú của tôi về tái cấu trúc tự động là không thể trong các lang được gõ động. Tôi hoàn toàn đồng ý với phần "cá nhân" của Haylem .... tất nhiên bỏ qua SmallTalk :) Điều này công bằng, ở một mức độ nào đó, vì SmallTalk, trong khi chưa chết, chắc chắn không được hưởng sự phổ biến mà Python hay Ruby có (hiện tại vào tháng 10 năm 2010 ).
Dan Rosenstark

3
@haylem, cá nhân tôi cảm ơn bạn vì đã khiến tôi cảm thấy rằng tôi không phải là người duy nhất trên thế giới làm việc bằng các ngôn ngữ động, nhưng khi được lựa chọn, nhiều lần LỰA CHỌN các ngôn ngữ được gõ tĩnh (cùng trường hợp, Java so với JRuby hoặc Groovy).
Dan Rosenstark

4
Thật thú vị bởi vì sở thích riêng của tôi đối với việc gõ động là vì những lý do khá khác nhau. Ý tôi là biên dịch nhanh và trình thông dịch tương tác rất hữu ích nhưng chúng không phải là lý do tại sao tôi thích gõ động. Tôi thích gõ động vì tôi thấy nhiều tình huống trong đó các ngôn ngữ gõ tĩnh chỉ gây khó khăn cho việc không thể mô tả một khái niệm cụ thể.
Winston Ewert

19

Mới hôm qua tôi đã tìm thấy nghiên cứu này: Thử nghiệm đơn vị là không đủ. Bạn cần gõ tĩnh quá.

Về cơ bản, tác giả đã sử dụng một công cụ có thể tự động chuyển đổi một dự án từ ngôn ngữ gõ không tĩnh sang một kiểu gõ tĩnh (python to haskell)

Sau đó, ông đã chọn một số dự án Python nguồn mở cũng bao gồm một lượng đơn vị thử nghiệm hợp lý và tự động chuyển đổi chúng thành haskell.

Bản dịch sang Haskell đã tiết lộ một loạt lỗi liên quan đến loại biến: các lỗi không được phát hiện bởi các đơn vị kiểm tra.


4
Sự thật khó chịu của gõ động.
Den

6
"Bản dịch sang Haskell đã tiết lộ một loạt lỗi liên quan đến loại biến: lỗi không được phát hiện bởi các đơn vị kiểm tra.": Với ngôn ngữ được gõ động, bạn phải kiểm tra thủ công các thuộc tính mã của mình theo cách tĩnh ngôn ngữ -typed được tự động kiểm tra bởi trình biên dịch. Điều này vừa tốn thời gian hơn vừa dễ bị lỗi. +1
Giorgio

4
Tôi đã trả lời một bài đăng trên liên kết này trên Reddit. Tôi không nghĩ rằng kết luận rút ra từ bài báo là hợp lý.
Veedrac

Cả hai hệ thống gõ đều có pro / nhược điểm và công dụng của chúng. Nó giống như thảo luận về việc mang một khẩu súng máy vào một cuộc chiến tay đôi. Đó là một cuộc chiến tôn giáo từ xa kết thúc. Điều đó nói rằng, tôi đồng ý với Veedrac. Các ngôn ngữ không tĩnh cần nhiều trường hợp kiểm tra hơn để bắt lỗi do các loại gây ra. Đó là bản chất và con của họ. Nhưng, một lập trình viên cần phải viết kiểm tra bắt lỗi trong mã gây ra bởi trạng thái đầu vào không mong muốn, không nhất thiết phải kiểm tra toàn diện cho loại đầu vào.
Andre Figueiredo

10
  • Liên kết để thảo luận về bài báo ACM " Một thử nghiệm về các hệ thống kiểu tĩnh và động " (2010) của bài viết của Stephan Hanenberg (được Lorin Hochstein tham khảo trong bài trước).
  • Kết luận: Năng suất cho chất lượng tương tự cao hơn trong một ngôn ngữ động.
  • Các vấn đề thiên vị / hiệu lực tiềm năng: Đối tượng thí nghiệm là tất cả các sinh viên. Ngoài ra, rất nhiều hạn chế của các nhiệm vụ lập trình (các đối tượng được yêu cầu triển khai trình quét và trình phân tích cú pháp).
  • Tài liệu ACM " Các ngôn ngữ lập trình có ảnh hưởng đến năng suất không? " (2007) của Delorey, Knudson và Chun.
  • Kết luận: JavaScript, Tcl, Perl năng suất cao hơn C # C ++ và Java. Python và PHP rơi vào giữa.
  • Các vấn đề sai lệch / hiệu lực tiềm năng: Không có thước đo về chất lượng (chẳng hạn như các lỗi được phát hiện sau khi phát hành). Không có thước đo độ tin cậy (phần mềm được viết bằng ngôn ngữ gõ tĩnh đáng tin cậy hơn?). Mẫu thiên vị - tất cả các dự án được mở từ các kho CVS nguồn mở. Ngoài ra, không có sự phân biệt giữa các ngôn ngữ được gõ yếu và mạnh (ví dụ: con trỏ).
  • Luận án " Nghiên cứu thực nghiệm về năng suất và chất lượng phần mềm " (2008) của Michael F. Siok
  • Kết luận: Lựa chọn ngôn ngữ lập trình không ảnh hưởng đáng kể đến năng suất hoặc chất lượng. Tuy nhiên, nó ảnh hưởng đến chi phí lao động và "chất lượng trong danh mục dự án phần mềm tổng thể".
  • Các vấn đề thiên vị / hiệu lực tiềm năng: Bị giới hạn trong miền avionics. Tất cả các ngôn ngữ lập trình có thể được gõ tĩnh. Tôi đã không đọc luận án, vì vậy tôi không thể đánh giá sự nghiêm ngặt của nó.
    Quan điểm của tôi. Mặc dù có bằng chứng yếu cho thấy các ngôn ngữ được gõ động có năng suất cao hơn, nhưng đó không phải là kết luận. (1) Có nhiều yếu tố không được kiểm soát, (2) có quá ít nghiên cứu, (3) có rất ít hoặc không có thảo luận về những gì tạo nên một phương pháp thử nghiệm thích hợp.

6

Đây là điểm khởi đầu:

Bài báo đang thách thức sự khôn ngoan thường nhận được rằng, tất cả những thứ khác đều bằng nhau, các lập trình viên viết cùng một số dòng mã mỗi lần bất kể ngôn ngữ. Nói cách khác, bài báo nên đóng vai trò là bằng chứng thực nghiệm cho thấy năng suất cơ học (dòng mã được viết) không phải là thước đo tốt về năng suất chức năng và ít nhất phải được chuẩn hóa bằng ngôn ngữ.


5
Đối với những người không phải là IEEE, tóm tắt cơ bản là gì?
Frank Shearar

1
@Frank Shearar, kết luận họ rút ra là ngôn ngữ lập trình không ảnh hưởng đến năng suất. Họ đang đo các dòng mã trên mỗi lập trình viên mỗi ngôn ngữ mỗi năm, tôi không chắc đó là thước đo năng suất tốt.
Winston Ewert

3
@Winston: Đó chắc chắn là một số liệu thiếu sót. Bạn sẽ thấy COBOL là một ngôn ngữ rất hiệu quả bởi nó: phải mất rất nhiều dòng để làm bất cứ điều gì hữu ích, nhưng chúng khá dễ viết.
David Thornley

Winston, David: Tôi khá chắc chắn rằng các tác giả không cho rằng năng suất dòng mã là thước đo năng suất chức năng . Thay vào đó, bài báo đang thách thức sự khôn ngoan thường nhận được rằng, tất cả những người khác đều bình đẳng, các lập trình viên viết cùng một số dòng mã mỗi lần bất kể ngôn ngữ. Nói cách khác, bài báo nên đóng vai trò là bằng chứng thực nghiệm cho thấy năng suất cơ học (dòng mã được viết) không phải là thước đo tốt về năng suất chức năng và ít nhất phải được chuẩn hóa bằng ngôn ngữ.
Pi Delport

Tôi đồng ý với điều đó. Nhưng nó không phục vụ để trả lời câu hỏi ban đầu của tôi.
Winston Ewert

1

Tôi đã tìm thấy một ngôn ngữ tĩnh so với các ngôn ngữ động: một đánh giá tài liệu , trong đó liệt kê một số nghiên cứu về chủ đề này và đưa ra một bản tóm tắt hay về mỗi nghiên cứu.

Đây là bản tóm tắt điều hành:

Trong số các thí nghiệm được kiểm soát, chỉ có ba cho thấy một hiệu ứng đủ lớn để có bất kỳ ý nghĩa thực tế nào. Nghiên cứu Prechelt so sánh C, C ++, Java, Perl, Python, Rexx và Tcl; nghiên cứu Endrikat so sánh Java và Dart; và thử nghiệm của Cooley với VHDL và Verilog. Thật không may, tất cả họ đều có những vấn đề khiến khó có thể đưa ra một kết luận thực sự mạnh mẽ.

Trong nghiên cứu của Prechelt, các quần thể khác nhau giữa các ngôn ngữ động và đánh máy, và các điều kiện cho các nhiệm vụ cũng khác nhau. Có một nghiên cứu tiếp theo minh họa vấn đề bằng cách mời Lispers đưa ra giải pháp riêng cho vấn đề, trong đó liên quan đến việc so sánh những người như Darius Bacon với sinh viên đại học ngẫu nhiên. Theo dõi theo dõi theo nghĩa đen liên quan đến việc so sánh mã từ Peter Norvig với mã từ các sinh viên đại học ngẫu nhiên.

Trong nghiên cứu Endrikat, họ đặc biệt chọn một nhiệm vụ trong đó họ nghĩ rằng gõ tĩnh sẽ tạo ra sự khác biệt và họ đã thu hút các đối tượng của họ từ một dân số nơi mọi người đã tham gia các lớp học bằng ngôn ngữ gõ tĩnh. Họ không bình luận về việc liệu sinh viên có kinh nghiệm trong ngôn ngữ gõ động hay không, nhưng có vẻ an toàn khi cho rằng hầu hết hoặc tất cả đều có ít kinh nghiệm hơn trong ngôn ngữ gõ động.

Thí nghiệm của Cooley là một trong số ít người thu hút mọi người từ dân số không phải là sinh viên, thật tuyệt vời. Nhưng, như với tất cả các thí nghiệm khác, nhiệm vụ là một nhiệm vụ đồ chơi tầm thường. Mặc dù có vẻ như không có ai trong số những người tham gia VHDL (ngôn ngữ tĩnh) có thể hoàn thành nhiệm vụ đúng hạn, nhưng việc hoàn thành thiết kế phần cứng trong 1,5 giờ ở bất cứ đâu ngoài dự án trường học là điều cực kỳ bất thường. Bạn có thể lập luận rằng một nhiệm vụ lớn có thể được chia thành nhiều nhiệm vụ nhỏ hơn, nhưng một phản biện chính đáng là có những chi phí cố định khi sử dụng VHDL có thể được khấu hao trong nhiều nhiệm vụ.

Đối với các thí nghiệm còn lại, điểm chính tôi nhận được từ chúng là, trong các tình huống cụ thể được mô tả trong các nghiên cứu, bất kỳ hiệu ứng nào, nếu nó tồn tại, đều nhỏ.

Chuyển sang nghiên cứu trường hợp, hai nghiên cứu trường hợp tìm lỗi giúp cho việc đọc thú vị, nhưng chúng không thực sự tạo ra trường hợp cho hoặc chống lại các loại. Một người cho thấy rằng việc sao chép các chương trình Python sang Haskell sẽ tìm thấy một số lỗi không nghiêm trọng có mức độ nghiêm trọng không xác định có thể không được tìm thấy thông qua thử nghiệm đơn vị theo định hướng bảo hiểm theo dòng. Cặp bài báo Erlang cho thấy rằng bạn có thể tìm thấy một số lỗi khó tìm thấy thông qua bất kỳ loại thử nghiệm nào, một số trong đó nghiêm trọng, sử dụng phân tích tĩnh.

Là người dùng, tôi thấy thuận tiện khi trình biên dịch của tôi gặp lỗi trước khi tôi chạy các công cụ phân tích tĩnh riêng biệt, nhưng đó là nhỏ, thậm chí có thể nhỏ hơn kích thước hiệu quả của các nghiên cứu được kiểm soát được liệt kê ở trên.

Tôi thấy nghiên cứu trường hợp 0install (so sánh các ngôn ngữ khác nhau với Python và cuối cùng giải quyết trên Ocaml) là một trong những điều thú vị hơn mà tôi đã chạy qua, nhưng đó là loại chủ quan mà mọi người sẽ diễn giải khác nhau, mà bạn có thể thấy bằng cách nhìn .

Điều này phù hợp với ấn tượng mà tôi có (ở góc nhỏ của tôi trên thế giới, ACL2, Isabelle / HOL và PVS là những provers được sử dụng phổ biến nhất và nó có ý nghĩa rằng mọi người sẽ thích tự động hóa hơn khi giải quyết các vấn đề trong công nghiệp), nhưng đó là cũng chủ quan.

Và sau đó là các nghiên cứu khai thác dữ liệu từ các dự án hiện có. Thật không may, tôi không thể tìm thấy bất cứ ai làm bất cứ điều gì để xác định quan hệ nhân quả (ví dụ: tìm một biến công cụ phù hợp), vì vậy họ chỉ đo lường mối tương quan. Một số tương quan là bất ngờ, nhưng không có đủ thông tin để xác định lý do.

Nghiên cứu khai thác dữ liệu duy nhất trình bày dữ liệu có khả năng thú vị mà không cần khám phá thêm là đánh giá về các lỗi Python của Smallshire, nhưng không có đủ thông tin về phương pháp để tìm hiểu ý nghĩa của nghiên cứu của ông và không hiểu tại sao ông lại nhìn vào dữ liệu cho các ngôn ngữ khác mà không cần trình bày dữ liệu3.

Một số thiếu sót đáng chú ý từ các nghiên cứu là các nghiên cứu toàn diện sử dụng các lập trình viên có kinh nghiệm, chứ đừng nói đến các nghiên cứu có số lượng lớn các lập trình viên giỏi Good, hay bad bad, nhìn vào bất cứ điều gì tiếp cận một dự án quan trọng (ở những nơi tôi đã làm việc, một dự án ba tháng sẽ được coi là nhỏ, nhưng đó là nhiều đơn hàng lớn hơn bất kỳ dự án nào được sử dụng trong nghiên cứu có kiểm soát), sử dụng ngôn ngữ gõ hiện đại, hiện đại, sử dụng cách gõ dần dần / tùy chọn, sử dụng IDE chính hiện đại (như VS và Eclipse), sử dụng IDE gốc hiện đại (như LightTable), sử dụng các trình soạn thảo trường học cũ (như Emacs và vim), bảo trì một cơ sở mã không tầm thường, bảo trì với bất cứ điều gì giống với môi trường thực tế, bảo trì một cơ sở mã mà bạn đã quen thuộc, v.v.

Nếu bạn nhìn vào bình luận trên internet về những nghiên cứu này, hầu hết chúng đều được thông qua để biện minh cho quan điểm này hay quan điểm khác. Nghiên cứu Prechelt về động so với tĩnh, cùng với các nghiên cứu tiếp theo về Lisp là những yêu thích lâu năm của những người ủng hộ ngôn ngữ động, và nghiên cứu khai thác github gần đây đã trở thành xu hướng của các lập trình viên chức năng.


0

Tôi thực sự không nghĩ rằng gõ tĩnh so với động là câu hỏi thực sự.

Tôi nghĩ rằng có hai tham số nên đến trước:

  • trình độ chuyên môn về ngôn ngữ: bạn càng có nhiều kinh nghiệm, bạn càng biết nhiều về "gotchas" và bạn càng có khả năng tránh chúng / theo dõi chúng dễ dàng. Điều này cũng đúng về ứng dụng / chương trình cụ thể mà bạn đang làm việc
  • thử nghiệm: Tôi thích gõ tĩnh (địa ngục tôi thích lập trình trong C ++: p) nhưng có rất nhiều thứ mà trình biên dịch / phân tích tĩnh có thể làm cho bạn. Không thể tự tin về một chương trình mà không thử nghiệm nó. Và tôi là tất cả để thử nghiệm mờ (khi áp dụng), vì bạn không thể nghĩ về tất cả các kết hợp đầu vào có thể.

Nếu bạn cảm thấy thoải mái về ngôn ngữ, bạn sẽ viết mã và bạn sẽ dễ dàng theo dõi các lỗi.

Nếu bạn viết mã tách rời và kiểm tra từng chức năng một cách rộng rãi, thì bạn sẽ tạo ra mã được mài giũa kỹ lưỡng, và do đó bạn sẽ làm việc hiệu quả (vì bạn không thể đủ điều kiện làm việc hiệu quả nếu bạn không đánh giá chất lượng sản phẩm, bạn có thể không? )

Do đó, tôi cho rằng cuộc tranh luận tĩnh và động liên quan đến năng suất là khá tranh luận, hoặc ít nhất là thay thế rất nhiều bởi những cân nhắc khác.


2
Nếu đây là một câu hỏi ngược, câu hỏi trong đó là ở đâu? :) Tôi đồng ý rằng các yếu tố khác quan trọng hơn là gõ tĩnh so với gõ động. Tuy nhiên, những người ủng hộ gõ động đòi hỏi năng suất tốt hơn và những người ủng hộ gõ tĩnh yêu cầu chất lượng mã tốt hơn. Tôi đã tự hỏi liệu có ai có bằng chứng thực tế để hỗ trợ cho yêu cầu của họ.
Winston Ewert

@Winston: Tôi đã xóa bit counter: p Như bạn đã đề cập, nó chủ yếu là các khiếu nại. Tôi nghĩ rằng hầu hết những người ủng hộ việc gõ động là pha trộn dễ sử dụng với gõ động, trong khi dễ sử dụng chủ yếu là về các công cụ. Tôi đồng ý rằng khả năng viết các nguyên mẫu vứt bỏ nhanh và thử nghiệm các lệnh ngắn bằng trình thông dịch là tăng năng suất, nhưng ngay cả Haskell (có lẽ là ngôn ngữ có hệ thống loại ấn tượng nhất thời điểm này) có trình thông dịch để thử nghiệm nhanh: )
Matthieu M.

Nhưng cho đến khi ai đó thực sự làm một nghiên cứu xem xét câu hỏi này - cho dù phương pháp, công cụ có tác động lớn hơn ngôn ngữ đối với tỷ lệ khuyết tật, năng suất - chúng ta mới kết thúc việc so sánh các giai thoại.
Frank Shearar

0

Ở đây có một ít:

  • Stefan Hanenberg. Năm 2010 Một thử nghiệm về hệ thống loại tĩnh và động: nghi ngờ về tác động tích cực của hệ thống loại tĩnh đối với thời gian phát triển. Trong Kỷ yếu của hội nghị quốc tế ACM về các ngôn ngữ và ứng dụng của hệ thống lập trình hướng đối tượng (OOPSLA '10). ACM, New York, NY, Hoa Kỳ, 22-35. DOI = 10.1145 / 1869459.1869462 http://doi.acm.org/10.1145/1869459.1869462

  • Daniel P. Delorey, Charles D. Knutson, Scott Chun, "Các ngôn ngữ lập trình có ảnh hưởng đến năng suất không? Một nghiên cứu tình huống sử dụng dữ liệu từ các dự án nguồn mở", floss, tr.8, Hội thảo quốc tế đầu tiên về xu hướng mới nổi trong nghiên cứu và phát triển FLOSS (FLOSS '07: Hội thảo ICSE 2007), 2007

  • Daly, M.; Sazawal, V., Foster, J.: Công việc đang tiến triển: một nghiên cứu thực nghiệm về gõ tĩnh trong Ruby, Hội thảo về đánh giá và khả năng sử dụng các ngôn ngữ và công cụ lập trình (PLATEAU) tại ON-WARD 2009.

  • Lutz Prechelt và Walter F. Tichy. 1998. Một thử nghiệm được kiểm soát để đánh giá lợi ích của việc kiểm tra loại đối số thủ tục. IEEE Trans. Mềm mại. Anh. 24, 4 (tháng 4 năm 1998), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.