동적 대 정적 언어 연구 [폐쇄]

정적 언어와 동적 언어의 효과에 대한 연구가 있습니까?

특히:

• 프로그래머 생산성 측정
• 결함 비율

또한 단위 테스트 사용 여부의 영향을 포함합니다.

나는 양쪽의 장점에 대해 많은 토론을 보았지만 누군가가 그것에 대해 연구했는지 궁금합니다.

일부 제안 읽기 :

• 개발자가 동적 언어로 전환 ( PDF )
• 역동적 인 언어의 부흥에 ( PDF )
• 가능한 경우 정적 타이핑, 필요할 때 동적 타이핑 : 프로그래밍 언어 간 냉전의 끝 ( PDF )
• 동적 연결을 통한 정적 입력 보안 ( PDF )
• 버그 감지를위한 정적 및 동적 추론 결합 ( PDF )
• 정적으로 입력 된 언어로 동적 입력 ( PDF )
• 프로그램 전문화를 통해 동적 입력을 정적 입력으로 변환 ( PDF )
• 하이브리드 유형 확인 ( PDF )

정적 타이핑은 아니지만 관련이 있습니다.

• 정적 분석 및 런타임 보호를 통한 웹 애플리케이션 코드 보안 ( PDF )

주제 또는 일반적으로 프로그램의 정적 분석에 관한 흥미로운 기사 또는 에세이 :

• 플러그 가능 유형 시스템 ( PDF )
• 강력한 타이핑 vs 강력한 테스트
• 정적 분석 버그 보고서에 대한 Linux 커널 개발자 응답 ( PDF )
• 약한 타이핑은 충분히 강합니까?
• 오류 순위의 상관 관계 악용
• 정적 분석을 통한 소프트웨어 품질 향상

그리고 이것이 무엇인지 궁금해하는 사람들을 위해 :

• 정적 및 동적 입력 소개

그러나, 나는 그들이 당신이 찾고있는 연구를 정확하게하지 않기 때문에 이것들 중 어느 것도 당신에게 직접적인 대답을 제공하지 않을 것입니다. 그래도 흥미로운 읽을 거리가 될 것입니다.

몸소동적 타이핑을 통한 정적 타이핑은 버그 감지를 용이하게한다는 점을 확실하게 생각합니다. 나는 오타와 같은 작은 실수를 JavaScript 나 Ruby 코드로 찾는 데 너무 많은 유형을 소비합니다. 다이내믹 타이핑 (Dynamic Typing)이 생산성을 향상 시킨다는 관점에서 볼 때 나는 주로 툴링에 달려 있다고 생각합니다. 정적으로 유형이 지정된 언어에 백그라운드 재 컴파일을 허용하고 REPL 인터페이스를 제공 할 수있는 올바른 도구가 있다면 두 가지 이점을 모두 누릴 수 있습니다. 스칼라는이를 통해 대화 형 콘솔에서 배우고 프로토 타입을 쉽게 만들 수 있지만 정적 타이핑 (및 다른 언어, ML 언어를 제외한 다른 언어보다 강력한 유형 시스템)의 이점을 제공합니다. 마찬가지로, 정적 입력 때문에 Java 또는 C ++를 사용하여 생산성이 저하되지 않는다고 생각합니다. 내가 도와주는 IDE를 사용하는 한. 간단한 구성 (편집기 + 컴파일러 / 인터프리터)으로 만 코딩으로 되 돌리면 더 번거롭고 역동적 인 언어를 사용하는 것이 더 쉬워 보입니다. 그러나 여전히 버그를 찾아야합니다. 사람들은 툴링 문제가 역동적 인 언어에 대해 더 나은 것처럼 툴링 문제가 가역적 인 논쟁이라고 말할 것입니다. 그래서 대부분의 버그와 오타가 코딩 타임에 지적되지만 시스템의 결함을 반영한다고 생각합니다. 아직도, 나는 보통 JRuby에서 프로토 타입을 만들고 나중에 내가하는 대부분의 일을 Java로 코딩 할 것이다. 툴링이 동적 언어에 더 나은 것처럼 대부분의 버그와 오타는 코딩 타임에 지적되었지만 시스템의 결함을 반영한다고 생각합니다. 아직도, 나는 보통 JRuby에서 프로토 타입을 만들고 나중에 내가하는 대부분의 일을 Java로 코딩 할 것이다. 툴링이 동적 언어에 더 나은 것처럼 대부분의 버그와 오타는 코딩 타임에 지적되었지만 시스템의 결함을 반영한다고 생각합니다. 아직도, 나는 보통 JRuby에서 프로토 타입을 만들고 나중에 내가하는 대부분의 일을 Java로 코딩 할 것이다.

경고 : 이 링크 중 일부는 신뢰할 수 없으며, 일부는 멤버에 대한 요금 기반 액세스를 사용하여 다양한 컴퓨팅 사회의 포털을 통과합니다. 죄송합니다. 각 링크마다 여러 개의 링크를 찾으려고했지만 원하는만큼 좋지 않습니다.

어제 나는이 연구를 발견했습니다 : 단위 테스트로는 충분하지 않습니다. 정적 입력도 필요합니다.

기본적으로 저자는 프로젝트를 비 정적 타이핑 언어에서 정적 타이핑 언어 (python to haskell)로 자동 변환 할 수있는 도구를 사용했습니다.

그런 다음 합리적인 양의 테스트 단위가 포함 된 다수의 오픈 소스 Python 프로젝트를 선택하여 자동으로 haskell로 변환했습니다.

Haskell 로의 번역은 변수 유형과 관련된 일련의 오류를 밝혀 냈습니다. 오류는 테스트 장치에서 발견되지 않았습니다.

• Stephan Hanenberg 기사 의 ACM 논문 " 정적 및 동적 유형 시스템에 대한 실험 "(2010)에 대한 토론 링크 (이전 게시물에서 Lorin Hochstein이 언급 함).
• 결론 : 유사한 품질의 생산성은 역동적 인 언어에서 더 높았습니다.
• 잠재적 편견 / 유효성 문제 : 실험 과목은 모두 학생이었습니다. 또한 다양한 프로그래밍 작업이 제한되었습니다 (대상은 스캐너와 파서를 구현하도록 요청했습니다).

  ---

• ACM 논문 " 프로그래밍 언어가 생산성에 영향 을 미치는가 ? "(2007) Delorey, Knudson, Chun.
• 결론 : JavaScript, Tcl, Perl은 C # C ++ 및 Java보다 생산성이 높습니다. 파이썬과 PHP는 중간에 떨어집니다.
• 잠재적 편향 / 유효성 문제 : 품질 측정 (예 : 릴리스 후 발견 된 버그)이 없습니다. 신뢰성의 척도는 없습니다 (정적으로 유형이 지정된 언어로 작성된 소프트웨어가 더 신뢰할 수 있습니까?). 샘플 편견 – 모든 프로젝트는 오픈 소스 CVS 저장소에서 가져 왔습니다. 또한 약한 유형과 강력한 유형의 언어 (예 : 포인터)를 구분하지 않습니다.

  ---

• Michael F. Siok의 논문 " 소프트웨어 생산성 및 품질에 대한 실증적 연구 "(2008)
• 결론 : 프로그래밍 언어의 선택은 생산성이나 품질에 큰 영향을 미치지 않습니다. 그러나 인건비 및 "전체 소프트웨어 프로젝트 포트폴리오 내 품질"에 영향을 미칩니다.
• 잠재적 편향 / 유효성 문제 : 항공 전자 분야로 제한됩니다. 프로그래밍 언어는 모두 정적으로 입력 될 수 있습니다. 논문을 읽지 않았기 때문에 논문의 엄격 성을 평가할 수 없습니다.

  ---

  내 의견 동적으로 유형이 지정된 언어가 더 생산적이라는 증거는 없지만 결정적인 것은 아닙니다. (1) 통제되지 않은 많은 요인들이있다. (2) 연구가 너무 적다. (3) 적절한 시험 방법을 구성하는 것에 대한 논의가 거의 또는 전혀 없다.

시작점은 다음과 같습니다.

• 프로그래밍 언어가 생산성에 영향을 줍니까? 오픈 소스 프로젝트의 데이터를 사용한 사례 연구 (Delorey, Knutson, Chun, 2007)

이 논문은 프로그래머가 언어와 상관없이 한 번에 같은 수의 코드 줄을 작성한다는 공통된 지식에 도전하고있다. 다시 말해,이 논문은 기계적 생산성 (코드 라인 작성)이 기능적 생산성의 좋은 척도 가 아니며 적어도 언어로 정규화되어야 한다는 경험적 증거를 뒷받침 해야합니다.

나는 정적 대 동적 언어를 발견했습니다 : 문학 검토 , 주제에 대한 일부 연구를 나열하고 각 연구에 대한 좋은 요약을 제공합니다.

임원 요약은 다음과 같습니다.

통제 된 실험 중에서 단 3 개만이 실질적인 의미를 가질만큼 큰 효과를 나타냅니다. C, C ++, Java, Perl, Python, Rexx 및 Tcl을 비교 한 Prechelt 연구; Java와 Dart를 비교 한 Endrikat 연구; Cooley의 VHDL 및 Verilog 실험. 불행히도, 그들은 모두 정말로 강력한 결론을 내리기가 어려운 문제가 있습니다.

Prechelt 연구에서 인구는 동적 언어와 유형 언어 사이에 차이가 있었고 작업 조건도 서로 다릅니다. 다리우스 베이컨 (Larius Bacon)과 같은 사람들을 무작위 학부생과 비교하는 것을 포함하는 문제를 해결하기 위해 Lispers를 초대하여 문제를 설명하는 후속 연구가있었습니다. 후속 조치에 대한 후속 조치는 말 그대로 Peter Norvig의 코드를 임의 대학생의 코드와 비교하는 것입니다.

Endrikat 연구에서 그들은 정적 타이핑이 차이를 만들 것이라고 생각하는 과제를 구체적으로 선택했으며 모든 사람들이 정적으로 타이핑 된 언어를 사용하여 수업을 수강 한 사람들로부터 과목을 그렸습니다. 학생들은 동적 유형 언어에 대한 경험이 있는지 여부에 대해서는 언급하지 않지만 대부분 또는 모두 동적 유형 언어에 대한 경험이 적은 것으로 가정하는 것이 안전 해 보입니다.

Cooley의 실험은 학생들이 아닌 학생들로부터 사람들을 끌어 들인 몇 안되는 것 중 하나였습니다. 그러나 다른 모든 실험과 마찬가지로이 작업은 사소한 장난감 작업이었습니다. VHDL (정적 언어) 참가자 중 어느 누구도 제 시간에 과제를 완수 할 수는 없었지만, 학교 프로젝트 외부에서 1.5 시간 안에 하드웨어 설계를 마치는 것은 매우 드문 일입니다. 큰 작업을 여러 개의 작은 작업으로 나눌 수 있다고 주장 할 수도 있지만 VHDL을 사용하여 고정 된 비용이 발생하여 여러 작업에서 상각 될 수 있다는 반박의 여지가 있습니다.

나머지 실험에 관해서, 내가 그들로부터 얻은 주요한 견해는 연구에 설명 된 특정 상황 세트에서 영향이 전혀 없다면 그 영향이 작다는 것입니다.

사례 연구로 넘어 가면서 두 가지 버그 찾기 사례 연구는 흥미로운 독서를 위해 만들어 지지만 실제로 유형에 대해 대립하지는 않습니다. 하나는 파이썬 프로그램을 하스켈로 전사 할 때 라인 커버리지 중심의 단위 테스트를 통해 찾을 수없는 심각도를 알 수없는 0이 아닌 수의 버그를 발견한다는 것을 보여줍니다. Erlang 논문은 정적 분석을 사용하여 모든 종류의 테스트를 통해 찾기 어려운 버그를 발견 할 수 있음을 보여줍니다.

사용자로서 별도의 정적 분석 도구를 실행하기 전에 컴파일러에서 오류가 발생하면 편리하지만 위의 제어 된 연구의 효과 크기보다 작을 수도 있습니다.

0install 사례 연구 (다양한 언어를 Python과 비교하고 결국 Ocaml에 정착 한)가 내가 찾은 흥미로운 것 중 하나라는 것을 알았지 만 모두가 다르게 해석 할 수있는 주관적인 것입니다. .

이것은 내가 가진 인상에 적합합니다 (세계의 작은 구석에서 ACL2, Isabelle / HOL 및 PVS가 가장 일반적으로 사용되는 프로 버이며 사람들이 업계에서 문제를 해결할 때 더 많은 자동화를 선호한다는 것이 합리적입니다). 또한 주관적입니다.

그리고 기존 프로젝트에서 데이터를 추출하는 연구가 있습니다. 불행하게도, 인과 관계를 결정하기 위해 무엇인가 (예를 들어, 적절한 도구 변수를 찾는) 사람을 찾을 수 없었기 때문에, 그들은 단지 상관 관계를 측정합니다. 일부 상관 관계는 예상치 못한 것이지만 그 이유를 판단 할 정보가 충분하지 않습니다.

추가 탐색없이 잠재적으로 흥미로운 데이터를 제공하는 유일한 데이터 마이닝 연구는 Smallshire의 Python 버그 검토이지만 그의 연구가 실제로 의미하는 바를 파악할 수있는 방법론에 대한 정보는 충분하지 않으며, 왜 그가 연구를했는지 힌트를 얻지 못했습니다. 데이터를 제시하지 않고 다른 언어에 대한 데이터 3.

이 연구에서 주목할만한 몇 가지 생략은 숙련 된 프로그래머를 사용하는 포괄적 인 연구이며, 많은 "좋은"또는 "나쁜"프로그래머 집단이있는 연구는 물론 중요한 프로젝트에 접근하는 모든 것을 살펴 보는 것입니다 (내가 일한 장소에서 3 개월 프로젝트는 "현대"정적 유형 언어, 점진적 / 선택적 타이핑, 최신 주류 IDE (VS 및 Eclipse와 같은), 최신 급진적 IDE를 사용하여 통제 된 연구에 사용 된 프로젝트보다 몇 배나 더 큰 것으로 간주됩니다. (Emacs 및 vim과 같은) 구식 편집자를 사용하여 사소하지 않은 코드베이스에서 유지 관리, 현실적인 환경과 유사한 모든 항목으로 유지 관리, 이미 익숙한 코드베이스에서 유지 관리 등

이러한 연구에 대한 인터넷 논평을 보면 대부분의 견해가 다른 견해를 정당화하기 위해 전달됩니다. Lisp에 대한 후속 조치와 함께 동적 대 정적에 대한 Prechelt 연구는 동적 언어 옹호자들이 오랫동안 즐겨 찾는 주제이며, github 마이닝 연구는 최근 기능 프로그래머들 사이에서 유행이되었습니다.

정직하고 정적 인 타이핑이 실제 질문이라고 생각하지 않습니다.

먼저 두 가지 매개 변수가 있어야한다고 생각합니다.

• 언어의 전문성 수준 : 경험이 많을수록 "gotchas"에 대해 더 많이 알수록 쉽게 피하고 추적 할 수 있습니다. 작업중인 특정 응용 프로그램 / 프로그램에 대해서도 마찬가지입니다.
• 테스트 : 정적 타이핑을 좋아하지만 (C ++ : p의 프로그래밍을 좋아합니다) 컴파일러 / 정적 분석기가 할 수있는 일이 너무 많습니다. 프로그램을 테스트하지 않고 확신을 갖는 것은 불가능합니다. 그리고 가능한 모든 입력 조합에 대해 생각할 수 없기 때문에 퍼지 테스트 (해당되는 경우)에 대한 모든 것입니다.

언어에 익숙하다면 코드를 작성하고 버그를 쉽게 추적 할 수 있습니다.

분리 된 코드를 작성하고 각 기능을 광범위하게 테스트하면 잘 정돈 된 코드가 생성되므로 생산성이 높아집니다 (제품의 품질을 평가하지 않으면 생산적인 자격을 얻을 수 없기 때문에 가능합니까? )

따라서 생산성과 관련하여 정적 대 동적 토론이 상당히 어리 석거나 적어도 다른 고려 사항으로 대체되었다고 생각합니다.

몇 가지가 있습니다 :

• 스테판 하넨 버그 정적 및 동적 유형 시스템에 대한 실험 : 개발 시간에 정적 유형 시스템의 긍정적 영향에 대한 의문. 객체 지향 프로그래밍 시스템 언어 및 응용 프로그램에 대한 ACM 국제 회의 진행 (OOPSLA '10). ACM, 뉴욕, 뉴욕, 미국, 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 R & D의 신흥 트렌드에 관한 최초의 국제 워크숍 '07 : ICSE 워크숍 2007), 2007

• 데일리, M .; Sazawal, V., Foster, J .: 진행중인 작업 : Ruby의 정적 타이핑에 대한 실증적 연구, ON-WARD 2009에서 프로그래밍 언어 및 도구 (PLATEAU)의 평가 및 유용성에 대한 워크숍.

• Lutz Prechelt와 Walter F. Tichy. 절차 인수 유형 검사의 이점을 평가하기위한 통제 된 실험. IEEE Trans. 소프트웨어. 영어 24, 4 (1998 년 4 월), 302-312. DOI = 10.1109 / 32.677186 http://dx.doi.org/10.1109/32.677186