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.