정적 타이핑은 그만한 가치가 있습니까?

나는 타입 안전이없는 곳에서 파이썬으로 코딩을 시작한 다음 C # 및 Java로 옮겼습니다. 나는 파이썬에서 조금 더 빠르고 두통없이 작업 할 수 있다는 것을 알았지 만 다시 C # 및 Java 앱은 훨씬 더 높은 수준의 복잡성을 가지므로 파이썬에 내가 실제로 스트레스 테스트를 한 적이 없다.

Java 및 C # 캠프는 유형 안전이없는 것처럼 들리게합니다. 대부분의 사람들은 모든 종류의 끔찍한 버그를 겪게 될 것입니다.

이것은 언어 비교가 아니므로 컴파일 된 것과 해석 된 것과 같은 문제를 해결하지 마십시오. 개발 속도와 유연성에 타격을 줄만한 가치가있는 유형 안전성이 있습니까? 왜?

동적 타이핑이 더 빠르다는 의견의 예를 원하는 사람들에게 :

"개발 중에 동적으로 입력 된 언어를 사용하십시오. 더 빠른 피드백, 처리 시간 및 개발 속도를 제공합니다." -http : //blog.jayway.com/2010/04/14/static-typing-is-the-root-of-all-evil/

프로그래머가 동적으로 유형이 지정된 언어의 유형에 대해 걱정할 필요가 없다는 일종의 신화입니다.

동적으로 입력 된 언어에서 :

• 배열, 정수, 문자열, 해시 테이블, 함수 참조, 사전, 객체 또는 기타로 작업하고 있는지 여전히 알아야합니다.

• 그것이 객체라면, 당신은 그것이 속한 클래스를 알아야합니다.

• 이러한 유형 중 하나를 다른 유형으로 예상되는 변수 또는 함수 매개 변수에 지정하는 것은 거의 항상 오류입니다.

• 예를 들어 TCP 패킷을 채우는 경우 하위 수준에서 비트 수 또는 부호있는 부호와 부호없는 부호와 같은 것을 여전히 고려해야합니다.

• 실제로 빈 문자열을 원했던 0을 얻는 문제가 발생할 수 있습니다. 다시 말해, 여전히 유형 불일치 버그를 디버깅하고 있습니다. 유일한 차이점은 컴파일러가 오류를 포착하지 않는다는 것입니다.

• 나는 당신이 많은 타이핑을 저장하지 않는다고 주장한다 . 왜냐하면 함수 매개 변수가 코드에서 문서화하는 대신 어떤 유형의 함수 매개 변수를 주석으로 문서화하려는 경향이 있기 때문이다. 이것이 정적 유형 언어에서는 대부분 라이브러리에서만 볼 수있는 동적 유형 코드 전체에서 doxygen 스타일 주석 블록이 실제로 훨씬 더 인기가있는 이유입니다.

다이나믹 타입 언어의 프로그래밍 은 컴파일러가 항상 뒤처져 있지 않기 때문에 기분 이 좋지 않으며 숙련 된 프로그래머는 정적 타이핑이 잡을 수있는 버그를 찾아 수정하는 데 어려움을 겪지 않습니다. 그러나 정적 타이핑에서도 동적 타이핑이 가장 좋은 효율 증가 또는 버그 비율 감소와는 완전히 별개의 문제입니다.

유형이 강해, 그들은 더 당신을 도울 수 - 경우에 당신이 그들을 싸우는 제대로 대신를 사용합니다. 문제 공간을 반영하도록 유형을 설계하면 논리 오류가 런타임 충돌 또는 넌센스 결과 대신 컴파일 타임 유형 불일치가 될 가능성이 높습니다.

면책 조항 : 나는 타입 애호가입니다.)

귀하의 질문에 대답하기가 어렵습니다. 그 절충점 은 무엇입니까 ?

극단적 인 예를 들어 보겠습니다 : Haskell , 그것은 정적으로 입력되었습니다. 실제로 가장 강력한 유형의 언어 중 하나 일 것입니다.

그러나 Haskell은 특정 개념 (또는 인터페이스)에 맞는 모든 유형에서 작동하는 메소드를 작성한다는 점에서 Generic Programming을 지원합니다 .

또한 Haskell은 Type Inference를 사용 하므로 변수 유형을 선언 할 필요가 없습니다. 파이썬 인터프리터가 프로그램을 실행하여 계산하는 것처럼 컴파일하는 동안 정적으로 계산됩니다.

나는 정적 타이핑에 열심 인 대부분의 사람들이 실제로 다른 것에 대해 불평하고 있음을 발견했지만 (하위 유형은 다른 유형을 선호하기 위해 한 유형을 전환하는 고통) 정적 유형을 입력하는 동안 Haskell은 이러한 문제를 전혀 나타내지 않습니다 ...

간결한 예 :

-- type
factorial :: Integer -> Integer

-- using recursion
factorial 0 = 1
factorial n = n * factorial (n - 1)

기본 제공 지원 외에는 짧아지기가 어렵습니다.

일반 프로그래밍의 예 :

> reverse "hell­o" -- Strings are list of Char in Haskell
=> "olleh"
> reverse [1, 2, 3, 4, 5]
=> [5,4,3,2,1]

형식 유추의 예 :

> :t rever­se "hell­o"
:: [Char]

간단하게 계산할 수 있습니다.

• "hello"Char(로 표현됨 [Char]) 의 목록입니다.
• reverse유형에 적용하면 유형이 [A]반환됩니다.[A]

브라우저에서 사용해보십시오

나는 정적으로 형식화 된 언어와 동적으로 형식화 된 언어를 모두 좋아합니다. 나에게 유형 안전의 가장 큰 두 가지 장점은 다음과 같습니다.

1) 타입 시그니처에서 함수가하는 일을 대부분 추론 할 수 있습니다 (하스켈과 같은 기능적 언어에서 특히 그렇습니다).

2) 중요한 리팩터링을 수행하면 컴파일러는 모든 작업을 유지하기 위해해야 ​​할 모든 것을 자동으로 알려줍니다. C ++에서 무언가를 리팩토링 할 때, 종종 내 절차는 단순히 a) 내가 변경하고 싶은 부분을 변경 한 다음 b) 모든 컴파일 오류를 수정합니다.

개인적으로, 나는 타입 안전이 현재 직장에서 더 빨리 발전하는 데 도움이된다는 것을 알게되었습니다. 컴파일러는 입력 할 때 거의 온전한 상태 검사를 수행하므로 구현중인 비즈니스 논리에 더 집중할 수 있습니다.

결론은 유연성이 떨어지지 만 유형 문제를 추적하는 데 시간이 걸리는 것입니다.

이 논쟁을 둘러싼 강력한 의견이 많이 있지만 분명이 실제로 의견의 문제가 아니다, 그것의 문제 사실 . 따라서 우리는 경험적 연구를 살펴 봐야 합니다. 그리고 그 증거는 분명합니다.

그렇습니다 . 정적 타이핑은 약간의 가치가 아니라 실제로 실질적인 절충점의 가치가 있습니다. 사실, 확실한 증거는 정적 타이핑이 코드의 버그 수를 15 % 이상 줄일 수 있다는 것을 보여줍니다 (이는 추정치가 낮고 실제 백분율은 거의 확실합니다). 그것은 엄청나게 높은 숫자입니다. 정적 타이핑을지지하는 사람들조차도 그렇게 큰 차이를 만들지 않았다고 생각합니다.

누군가가 당신에게 프로젝트의 버그를 밤새 15 % 줄이는 간단한 방법이 있다고 말하면, 그것은 쉬운 일이 아닙니다. ¹ 그것은 거의 속담의 총알입니다.

그 증거는 Zheng Gao, Christian Bird 및 Earl T. Barr 의 논문에 타이핑하거나 타이핑하지 말아야 할 것들 : JavaScript에서 감지 가능한 버그의 정량화에 나와 있습니다. 나는 모든 사람이 그것을 읽을 것을 권장합니다. 그것은 훌륭한 연구를 제시하는 잘 작성된 논문입니다.

저자가 얼마나 엄격하게 분석을 수행했는지 간결하게 요약하기는 어렵지만 여기에는 (매우 거친) 개요가 있습니다.

TypeScript 및 Flow 는 JavaScript를 기반으로하는 두 가지 프로그래밍 언어로, 호환되는 방식으로 유형 힌트 및 정적 유형 검사를 추가합니다. 이를 통해 기존 코드를 유형별로 확장 한 다음 유형을 확인할 수 있습니다.

연구원들은 GitHub에서 JavaScript로 작성된 오픈 소스 프로젝트를 수집하고, 해결 된 버그 보고서를보고,보고 된 각 버그를 TypeScript 또는 Flow의 정적 유형 검사기에서 잡을 수있는 코드 조각으로 줄이기 위해 시도했습니다. 이를 통해 정적 타이핑을 사용하여 버그 비율의 하한을 추정 할 수있었습니다.

연구원들은 분석을 통해 유형과 관련이없는 버그를 유형과 관련이있는 것으로 간주하지 않도록 엄격한 예방 조치를 취했습니다. ²

과거의 연구와 비교할 때이 새로운 연구에는 다음과 같은 장점이 있습니다.

• 가 직접 정적의 비교 대 자바 스크립트와 타이프 라이터 / 흐름 사이의 유일한 차이점은 입력이기 때문에 (있는 경우) 몇 가지 혼란 변수 동적 타이핑은.
• TypeScript와 Flow (예 : 다른 유형 시스템)를 모두 확인하고 다른 사람이 (수동) 유형 주석을 재현하여 버그를 수정함으로써 여러 차원에서 복제를 수행합니다. 그리고 다른 프로젝트의 수많은 코드 기반에서이 작업을 수행합니다.
• 이 백서는 정적 타이핑이 수정 가능한 버그 에 대한 직접적인 영향을 측정합니다 (약간의 모호한 품질이 아닌).
• 저자는 무엇을 측정하고 어떻게 사전에 엄격한 모델을 정의합니다. 또한 설명은 매우 명확하고 결함을 쉽게 분석 할 수 있도록합니다 (연구 논문이 공격에 노출 될 때 항상 좋습니다 : 공격이 주장을 찌그러 뜨리지 않으면 더 강해집니다). ^삼
• 표본 크기가 충분하고 후속 통계 분석이 완전 하도록 적절한 검정력 분석을 수행합니다 .
• 혼란스러운 설명을 배제하고 하나의 움직이는 부분 만 측정하기에는 지나치게 보수적입니다. 또한 유형을 포함하여 즉시 수정 가능한 버그로 분석을 제한하고 입력을 수용하기 위해 고급 리팩토링이 필요한 항목은 제외합니다. 실제로 실제로 그 효과는 그다지 크지 않지만 확실히 그들이보고 한 것보다 작지 않습니다.
• 그리고 마지막으로, 그들은 약간의 효과가 아니라 놀라운 차이를 발견했습니다 . 지나치게 보수적 인 절차에도 불구하고 95 % 신뢰 구간의 최저 수준에서도 최소한 추가 유형 검사만으로도 사라지는 버그의 10 % 이상이 발견됩니다.

아직 아무도 발견하지 못한 논문에 근본적인 결함이 없다면, 논문은 거의 비용없이 정적 타이핑의 큰 이점을 결정적으로 보여줍니다. ⁴

역사적으로, 프로그래밍 분야의 타이핑 분야에 대한 연구는 오랜 시간 동안 증거 가 전혀 명확 하지 않았기 때문에 어려운 시작 이었습니다 . 그 이유는 정적 대 동적 타이핑 의 효과를 검사하기 위해 체계적인 실험을 수행하는 것이 쉽지 않기 때문입니다. 체계적인 실험은 조사중인 효과를 분리해야합니다. 불행히도 우리는 프로그래밍 언어에 묶여 있기 때문에 타이핑 규칙의 효과를 분리 할 수 ​​없습니다.

실제로이 있었다 (와 예 VB 정적 및 동적 모두 다른 방언의 입력을 허용 프로그래밍 언어 Option Strict On나 Off, 또는 정적으로 리스프를 입력은). 그러나 이것들은 직접 비교에 적합하지 않았으며, 가장 중요한 것은 직접 비교할 수있는 기존의 충분히 큰 코드 기반이 없기 때문입니다. 기껏해야“실험실 설정”에서 테스트 대상이 정적으로 또는 동적으로 유형이 지정된 언어 변형으로 작업을 임의로 해결하는 것을 비교할 수있었습니다.

불행히도 이러한 인공 프로그래밍 할당은 실제 사용을 잘 모델링하지 않습니다. 특히, 이들 중 다수는 범위가 작고 텍스트의 반 페이지에 요약 될 수있는 잘 정의 된 문제를 해결합니다.

운 좋게도 TypeScript, Flow 및 JavaScript는 정적 타이핑을 제외하고는 실제로 동일한 언어이며 샘플링 할 코드 및 버그에 대한 광범위한 실제 데이터 세트가 있기 때문에 과거에는 마찬가지입니다.

_{¹ 원본 논문의 인용문에서 영감을 얻었습니다.}

_{² 나는 이것에 완전히 만족하지 않는다. 정적으로 형식화 된 언어의 주요 강점 중 하나는 표면적으로 형식과 관련이없는 문제를 정적으로 형식 검사 할 수있는 방식으로 표현할 수 있다는 것이다. 이것은 많은 논리 오류를 유형 오류로 변환 하여 정적 입력에 의해 잡힐 수있는 버그의 비율 을 크게 증가시킵니다. 실제로이 백서는 유형과 관련이없는 버그를 대략 분류하고 있으며, 실제로는 정적 타이핑으로 인해 많은 부분이 발견 될 수 있다고 주장합니다.}

_{³ 분석에서 해결되지 않은 결함을 찾아 보도록 역동적 인 타이핑을지지하는 사람을 초대합니다. 나는 많은 것이 있다고 생각하지 않으며, 잠재적 결함이 결과를 실질적으로 변화시키지 않을 것이라고 확신합니다.}

_{⁴ 실제 대규모 프로젝트에서 정적 타이핑의 실제 비용이 존재하지 않는 것 같습니다. 아키텍처의 자연스러운 부분이되어 계획을 단순화 할 수도 있기 때문 입니다. 정적 유형 오류 수정에는 시간이 걸리지 만 나중에 발견되는 오류보다 훨씬 적습니다. 이것은 광범위하게 실험적으로 연구되어 왔으며 수십 년 동안 알려져왔다 (예 : Code Complete 참조 ).}

개발 속도와 유연성에 치명적인 유형 안전성이 가치가 있습니까?

실제로 이것은 당신이하는 일에 달려 있습니다. 비행기의 백업 시스템을 프로그래밍하는 경우 유형 안전이 가장 좋은 방법 일 것입니다.

동적 언어와 정적 언어 프로그래밍은 실제로 두 가지 다른 동물입니다. 둘 다 근본적으로 다른 접근 방식이 필요합니다. 정적과 동적 사이에 접근 방법을 주로 이식 할 수 있지만 다른 방법의 장점을 잃게됩니다.

정말 사고 방식입니다. 하나는 다른 것보다 낫습니까? 그것은 실제로 당신이 누구이고 어떻게 생각 하느냐에 달려 있습니다. 내가 함께 일하는 대부분의 사람들은 실수 할 공간이 너무 많다고 느끼기 때문에 필요없는 경우 동적 인 언어를 만지지 않을 것입니다. 그들은 이것을 생각하는 것이 잘못입니까? 물론 아닙니다. 그러나 코딩 스타일을 적용하는 방식이 역동적 인 환경에서는 작동하지 않는다는 것을 깨달았습니다. 내가 사용자 그룹에가는 다른 사람들은 정반대입니다. 정적 타이핑은 너무 번거 롭습니다. 특정 유형의 문제를 해결하기위한 접근 방식이 제한되어 있기 때문입니다.

솔직히 말하면 JavaScript와 C # 사이를 많이 뛰어 넘습니다. 이제 두 언어를 모두 알고 이해하는 것이 다른 언어에 어느 정도 영향을 미치지 만 실제로는 각 코드로 작성된 코드가 완전히 다릅니다. 그들은 근본적으로 다르기 때문에 다른 접근법이 필요합니다. 내가 찾은 것은 "만약 X 언어로 이것을하기가 훨씬 어렵다"는 생각이 든다면, 당신의 접근 방식은 약간 어려울 것입니다. 다음은 사람들이 말하는 "Pythonic"방식에 대한 예입니다. 의미하는 것은 파이썬 언어가 문제를 더 쉽게 만들기 위해 작동하는 방법이 있다는 것입니다. 다른 방법으로하는 것은 일반적으로 어렵고 더 성가신 일입니다. 언어가 실제로 어떻게 작동하는지 아는 혹을 극복해야합니다. 그것'

최근에 비슷한 질문이있었습니다. 웹 사이트의 동적 언어와 정적 언어

내 대답의 핵심을 다시 말하면 :

시스템이 커짐에 따라 정적으로 유형이 지정된 언어는 구성 요소 수준에서 견고성을 보장하므로 시스템 수준에서 유연성을 보장합니다.

그렇습니다. Java는 엄격하게 입력되어 있습니다. 그렇습니다. Java는 짜증나 지 않습니다.
그러나 그로부터 추측하면, 엄격한 타이핑은 짜증납니다. 그것은 PHP를 가리키고 동적 타이핑을 유추하는 것과 같습니다 (다시 말하지만, 공격은 없습니다. 천천히 개선되고 있습니다.).

개인적 으로 정적 유형 시스템을 가진 haXe 에서 대부분의 개발 작업을 수행 합니다. Java보다 훨씬 표현력이 좋을뿐만 아니라 형식 유추로 인해 훨씬 ​​적은 노력이 필요하지만 선택 사항이기도합니다. 방해가된다면 우회하면됩니다.

유형 안전은 발에 직접 쏘지 않도록 도와주는 기능입니다 (이것은 많은 고급 언어가 제대로 이해하지 못하는 것입니다) .
그리고 코드 유형을 마음대로 확인하는 옵션이 있다면 성공적으로 동적으로 유형이 지정된 언어가 더 좋습니다.
예를 들어, 나는 루비를 실험하는 것을 좋아했지만 루비는 완전히 객체 지향적이기 때문에 컴파일 시간 유형 시스템의 존재와 완전히 직교하기 때문이다.

저는 정적 타입 시스템이 눈에 잘 띄지 않는다는 주장은 단지 좋은 정적 타입 시스템에 대한 지식이 부족하기 때문입니다. 올바른 언어를 사용하는 언어가 여러 개 있는데, 그중 하나 일뿐 아니라 그 점에서 최고가 아닐 수도 있습니다.

haXe 코드 예 :

class Car {
    public function new();
    public function wroom() trace('wroooooooom!')
}
class Duck {
    public function new();
    public function quack(at) trace('quackquack, ' + at + '!')
}

function letQuack(o) o.quack();
letQuack(new Car());
letQuack(new Duck());

컴파일 시간 오류가 발생합니다.

Car should be { quack : Void -> Unknown<0> }
Car has no field quack
For function argument 'o'
Duck should be { quack : Void -> Unknown<0> }
Invalid type for field quack :
to : String -> Void should be Void -> Unknown<0>
For function argument 'o'

타입 안전에 많은 노력을 기울여야한다고 주장 할 수는 없습니다.

테스트가 더 어리석기 때문에 타입 안전이 필요하지 않다고 말합니다. 작문 시험은 지루하고 반복적입니다. 그리고 실제로 테스트를 작성하고 싶지는 않습니다. 단지 Car의 인스턴스가 흔들리지 않으며 오리는 누군가를 흔들어야한다는 것을 알았습니다.

하루가 끝나면 오버 헤드 유형 안전 비용이 어느 정도 들었더라도 결국에는 상실됩니다 (자바에서도-하지만 그렇게 빨리는 아닙니다).

어떤 이유로 든 더 이상 종종 더 이상 객체 유형과 관련된 오류를 만들지 않습니다. C #과 같은 언어에서는 컴파일러가 감지 할 수있는 유형 안전 오류를 만드는 것보다 런타임 캐스트와 관련된 오류가 발생할 가능성이 높습니다.이 오류는 일반적으로 정적으로 정적을 해결해야 할 때 발생합니다 입력 언어. 루비를 작성할 때 코드는 객체의 유형에 대해 매우 강력하게 암시하는 경향이 있으며 REPL의 가용성은 원하는 방법 / 속성이 존재하는지 이미 실험적으로 확인했음을 의미합니다. 그렇지 않으면 단위 테스트를 수행합니다. 기본적으로 같은 것이므로 루비에서 유형 안전 문제가 거의 발생하지 않습니다.

그러나 정적으로 유형이 지정된 시스템이 이전보다 더 나을 수는 없습니다.

정적으로 유형이 지정된 언어 내에서 유형 시스템도 실제로 중요합니다. 예를 들어, 기능 언어의 Some 모나드 (type <Some> : = yes x | no)와 같은 기능을 사용하면 대부분의 유형 시스템에서 일반적으로 두려운 NullReferenceException을 방지하는 컴파일 타임 검사가 수행됩니다. 패턴 일치 코드가 실행될 때 널 조건을 처리하지 못했다는 컴파일 시간 오류가 발생합니다 (해당 메커니즘을 사용하여 유형을 선언하는 경우). 또한 F #에서 파이프 라인 연산자와 같은 항목을 사용할 때 유사한 유형의 오류를 줄입니다.

Hindley–Milner 정적 타이핑의 전통에서는 유형 X가 인터페이스 X를 지원한다고 주장하는 것보다 훨씬 더 많은 것을 제공 할 수 있습니다. 일단 그러한 유형이 있으면 정적으로 유형이 지정된 시스템이 많이되었다고 말할 수 있습니다. 더 귀중한.

이것이 옵션이 아닌 경우 C #에 대한 계약 별 설계 확장은 정적 유형 시스템의 가치를 높이는 또 다른 메커니즘 세트를 추가 할 수 있지만 여전히 일부 기능적 패러다임보다 더 많은 규율이 필요합니다.

따라 다릅니다.

휴먼 모드는 종종 통계적입니다. 강력한 유형 검사는 몇 가지 특정 유형의 인적 실패 가능성을 줄입니다 (버기 코드 발생). 그러나 당신이 실패 할 수 있다고해서 항상 (Murphy non-withstanding)을 의미하는 것은 아닙니다.

잠재적 인 실패 확률의 감소가 비용 가치가 있는지 여부에 달려 있습니다.

원자력 발전소 또는 ATC 시스템 용 코드를 작성하는 경우 인적 장애 모드 감소가 매우 중요 할 수 있습니다 . 사양이없고 실패 결과가 거의없는 웹 사이트 아이디어를 신속하게 프로토 타이핑하는 경우 실패 모드 나 확률이 줄어들면 아무 것도 사지 않을 수도 있지만 개발 시간이 길어질 수 있습니다 (키 스트로크 등). 현재 필요한 유형을 암기하여 산만해진 뇌 세포.

Lisp로 작성된 매우 복잡한 시스템이 많이 있었으며 Lisper가 정적 타이핑을 원한다고 불평하는 것을 듣지 못했습니다. 내가 그것을 사용할 때 정적 유형 시스템 (및 공통 Lisp에서 유형을 정적으로 지정할 수 있음)이 잡았을 때 속도를 늦춘 문제를 기억하지 못합니다.

더욱이, 주류 정적 타입 언어는 오류를 잡기에는 적합하지 않은 것 같습니다. 레이아웃을 설계에서 중요한 것은 특정 수의 그것의 여부, 페이지의 수직 측정 점이다 int, unsigned, float, 또는 double. 반면에 컴파일러는 안전하지 않은 것으로 간주되는 유형 변환에 플래그를 지정하고 행복하게 세로 측정과 문자열의 문자 수를 추가 할 수 있습니다. 정적 유형 시스템의 이러한 약점은 Simonyi의 헝가리 표기법의 원래 아이디어였습니다.

유형은 인터페이스의 제약 조건이므로 단위 테스트로 테스트하려는 항목의 하위 집합이므로 많은 장단점이 비슷합니다.

• 정적 유형은 코드가 유형 시스템이 표현할 수있는 요구 사항을 충족하는지 여부에 대한 초기 피드백을 제공합니다 (고객 피드백 또는 더 높은 수준의 테스트와 같이 최소한의 기능을 구현하여 피드백 지연).
• 코드가 특정 요구 사항을 충족하면 리팩토링 및 디버깅이 쉬워 지지만 인터페이스 변경 및 요구 사항 변경에 오버 헤드가 추가됩니다.
• 특히 정적으로 유형이 지정된 언어에 강제력이없는 경우 버그를 유발하는 데이터에 사용되는 코드에 대해 추가 보안을 제공하지만 (조건부 및 어설 션의 필요성을 줄임) 지나치게 제한적인 제약 조건으로 인해 사용자가 자신의 데이터를 허용되는 형식 (예 : 명시 적 유형 캐스팅)
• 명시 적 형식 주석은 코드를 읽을 때 이해하는 데 도움이되거나 중복되거나 불필요한 정보로 코드를 어지럽 힐 수 있습니다.
• 구현에 따라 간결함을 떨어 뜨릴 수 있습니다. 유형 주석이 필요한지 또는 유추되는지, 유형 시스템이 일반 유형 / 인터페이스를 얼마나 잘 표현할 수 있는지, 구문 및 유형 시스템에 의해 표현 될 수있는 제약 조건을 테스트 하려는지 여부 (예 : 동일한 테스트는 단위 테스트보다 언어 기능보다 더 간결하지만 테스트를 의도하지는 않았을 수 있습니다.
• 또한 (TDD와 관련이없는) 정적 유형은 유형 확인을 요구하고 (확인하고 최적화를 수행하는 데 시간이 걸리는 대신) 컴파일 시간 최적화를 지원할 수 있으며 데이터가 유형으로 제한되는 경우 더 나은 최적화를 수행 할 수 있습니다. 하드웨어에 잘 매핑됩니다. 이렇게하면 성능 요구 사항이있는 코드 개발이 쉬워 지지만 이러한 제약 조건에 잘 맞지 않는 코드 (포인트 3)에 따라 문제가 발생할 수 있습니다.

요약하면 동적 언어가 프로토 타이핑에 특히 유용하지만 코드가 올바른지 확인하려면 강력한 유형 시스템을 선호해야합니다.

물론 이죠 강력한 형식의 언어와 Python (Python은 강력하게 형식화 됨)을 더 많이 사용함에 따라 동적 언어로 잘 작성된 코드는 강력하게 형식화 된 코드와 같은 규칙을 많이 따르는 경향이 있습니다. 동적 타이핑은 직렬화 및 역 직렬화에 매우 유용하지만 다른 대부분의 경우 실제로 많은 이점을 제공하지 않습니다. 그리고 대부분의 코드가 직렬화 관련이 아니라면 왜 무료 오류 검사를 포기합니까?

모건, 당신이 시도 할 흥미로운 아이디어가 있습니다 : 정적 + 동적 입력. Python, C # 및 Java를 언급했습니다. .NET과 Java 모두에 꽤 좋은 Python 포트가 있다는 것을 알고 있습니까? 두 경우 모두 포트를 사용하면 해당 플랫폼의 라이브러리를 사용하거나 기존 코드와 상호 운용 할 수 있습니다. 이것은 몇 가지 가능성을 제공합니다.

1. 레거시 코드를 유연하고 융통성없는 언어로 유지하십시오. 새로운 것을 위해 파이썬을 사용하십시오.
2. Python을 사용하여 성숙한 플랫폼 위에 새로운 것을 프로토 타입하십시오. 보다 성숙한 언어로 유지하려는 구성 요소를 다시 코딩하십시오.
3. 자주 변경하는 부분에 동적 언어를 사용하십시오.
4. 동적 언어를 사용하여 실행 코드 수정과 같은 아이디어를 가지고 놀아보십시오.
5. 강력한 형식의 언어를 사용하는 중요한 부분을 제외하고 동적 언어로 모든 작업을 수행하십시오.

나는 C / C ++에서 개발의 고통을 극복하기 위해 90 년대 후반까지이 접근법들을 사용했다. 나는 기본 라이브러리와 때로는 성능이 필요했습니다. 그러나 나는 더 나은 구문, 유연성, 안전성 등을 원했습니다. 다른 언어 / 플랫폼에 대해 전체 언어와 레거시 코드를 버리는 것보다 실제로 더 나은 경우가 많습니다.

(참고 : 이미 답변에서 말했지만 동적 타이핑! = 아니오 / 약한 타이핑을 다시 강조하고 싶습니다. 많은 동적 유형 시스템은 내부에서 강력한 타이핑을 사용합니다. 유형 역학을 만드는 것에 대해 생각하는 방식은 변수 유형은 런타임에 결정되며 유형 주석이 필요하지 않으며 런타임에 변경 될 수 있습니다.

당신은 그것에 대한 객관적인 대답을 얻지 못할 것이지만, 내 경험은 TDD를 마스터 할 때까지 유형 안전이 매우 중요하다는 것입니다 . 코드 전에 테스트가 작성된 단위 테스트 적용 범위가 크면 컴파일러 검사가 어려워지고 실제로 방해가되기 시작합니다.

이 질문이 많이 나오는 것을 보았습니다. 귀하의 소프트웨어 품질 (및 버그 없음)은 개발 프로세스, 시스템 구성 방법 및 코드 품질에 대한 귀하와 동료의 헌신과 관련이 있다고 생각합니다.

내 마지막 직업은 주로 파이썬 개발이었습니다. 국제 대형 웹 호스팅 회사에서 근무했으며 미국, 캐나다 및 한국에 개발 팀이있었습니다. 사용자가 도메인 이름과 웹 호스팅 계정을 관리 할 수 ​​있도록하는 프런트 엔드 고객 앱용 사용자 지정 Python 웹 프레임 워크 백엔드 : 모든 파이썬도. 파이썬 웹 서비스는 개별 웹 서버와 대화하여 새로운 웹 호스팅 사이트 제공, 새 블로그 생성, 이름 서비스 시스템에서 DNS 항목 생성 등의 작업을 수행합니다. 기타 등등. 나의 현재 직업에서 클라이언트는 우리 모두를 자바로 응용한다. 우리의 주요 제품은 자바와 플래시의 혼합입니다. 오래된 앱을위한 맞춤형 자바 웹 프레임 워크, 새로운 내부 툴을위한 개찰구.

두 가지 모두에서 일한 결과,이 질문을 볼 때마다 나에게 버그가 있다고 말해야합니다. 동적으로 유형이 지정된 언어를 사용하고 실제로 코드를 테스트하는 경우 문제가 없습니다. 시스템이 잘 설계되고 표준을 따르는 경우에는 문제가 없습니다. 컴파일러 검사 유형이 없기 때문에 많은 버그가 발생하지 않았습니다. 오늘날의 Java 작업과 마찬가지로 대부분의 버그는 논리적 오류였습니다.

개발 속도와 유연성에 타격을 줄만한 가치가있는 유형 안전성이 있습니까? 왜?

정적 타이핑은 소프트웨어 수명주기 동안 개발 속도와 유연성이 크게 향상 되었습니다. 그것은 총 노력과 불편을 줄이지 만, 더 눈에 띄는 곳에서 많은 노력과 불편을 미리 옮깁니다. 작업 코드를 갖는 데 대한 진입 장벽은 높지만 유형 검사기를 만족하여 해당 장벽을 벗어나면 코드를 확장하고 유지하는 데 훨씬 적은 작업이 필요합니다.

다음과 같은 이유로 소프트웨어 개발에 항상 어려움이 있습니다.

• 달성하려는 것의 본질적인 복잡성

• 인간의 본질적인 오류, 특히 우리가 더 복잡한 일을하려고 할 때 더 많은 실수를한다고 생각하면

조만간 이러한 문제를 해결하기 위해 시간이 필요합니다. 그 주위를 돌아 다니지 않습니다. 정적 타이핑은 이러한 문제를 나중에보다 빨리 해결합니다. 나중에 실수를 발견하면 ( if 의 경우 가 아니라 when ) 실수를 발견하면 그 실수를 바로 잡는 데 더 많은 비용이 들기 때문에 조만간 더 낫습니다 .

런타임에 발생한 유형 관련 예외를 디버깅하는 것보다 유형 검사기에서보고 한 실수를 수정하는 데 훨씬 적은 비용이 듭니다. 타입 검사를 런타임으로 연기하는 것은 단지 양탄자 아래에서 문제를 휩쓸고 있습니다.

이것은 단지 내 자신의 의견이지만, 유형 안전이 그만한 가치가 있다고 생각하지 않습니다. 잠깐만 요

나는 오랫동안 개발자였습니다. c ++, c #으로 시작한 다음 javascript (frontend 및 backend via node.js)로 이동했습니다. Javascript로 개발 한 이래로 유형 기반 언어를 사용하여 실제로 생산성이 급상승하는 시점까지 생산성이 급상승했습니다. 나는 또한 컴파일에 반대하고 있습니다. 지금 모든 것이 런타임에 있기를 바랍니다. 통역 된 언어는 실제로 프로그래밍에 대한 나의 사랑을 찾은 곳입니다.

유형에 관해서는, 나는 어떤 이점도 보지 못합니다. 메모리 관리와 같은 방식으로 유형이 표시됩니다. 완전히 불필요합니다. 미래의 언어는 개발자가 유형에 대해 아는 것을 완전히 차단해야합니다. 컴퓨터는 유형을 이해하고 개발자가 빠져 나가도록해야합니다.

다음은 예입니다. 방금 Swift (Apple의 새로운 언어)를 사용하고 있었는데 실제로 하루 전에 그 이름으로 살기를 바랐습니다. var n = 1/2이 작동하지 않았습니다. 나는 여기에 무슨 일이 있었는지 같았습니다. 슬프게도 var n : Float = 1/2을 수행해야한다는 것을 깨달았습니다. 이것은 내가 타이프 시스템을 얼마나 싫어하는지, 그리고 그들이 불필요하게 악화되는 정도를 상기시켜주었습니다.

나는 심지어 사용자 정의 유형 (예 : 클래스)을 원하지 않는다고 말하기 위해 또 다른 마일을 갈 것입니다. 나는 타입을 전혀 원하지 않습니다. 내가 원하는 것은 var와 객체입니다. 모든 객체를 객체로 사용할 수있는 경우 그리고 객체는 역동적이고 끊임없이 변화합니다. 작동하는 것과 작동하지 않는 것에 대해 런타임 문제가되는 곳

개발자들은 느슨하게 입력 된 언어가 큰 프로젝트에 얼마나 좋지 않은지 말하기를 좋아합니다. 그러나 나는 그 반대라고 말하고 싶습니다. 대규모 프로젝트에는 강력한 형식의 언어가 끔찍합니다. javascript가 큰 프로젝트에서 작동하지 않는다고 말하면 node.js / javascript 또는 PHP로 시작한 Facebook에서 모든 백엔드를 실행하는 40 억 대 이상의 회사에게 Uber에게 문의하십시오.

정적으로 유형이 지정된 언어로는 오늘날의 빠른 반복에 좋지 않습니다. 다음은 간단한 예입니다. 10 명의 개발자가 지속적인 통합 서버를 사용하여 .net 프로젝트에서 작업하고 있으며, 한 명의 개발자는 실수를 제출하고 전체 개발자가 중단되었습니다. 문제가되는 개발자가 실수를 바로 잡을 수 있습니다. 효율적인 허에 대해 이야기? 타입 시스템 / 정적 언어는 그런 식으로 상호 의존적이며 코드를 상호 의존적으로 만듭니다. 그러나 스크립트 파일은 상호 의존적이지 않습니다. 스크립트 중 하나에 문제가 있어도 프로덕션이 중단되지 않으면 보이는 모든 문제가 런타임에 남아 있습니다. 그리고 런타임이 멈추지 않습니다. 결코 끊어지지 않습니다. 출력이 잘못 될 수 있지만

예.

Java 또는 C # 에서처럼 유형이 "강하지 않은"PHP 응용 프로그램에서 작업했습니다. 일반적으로 잘못된 자동 변환이나 데이터 유효성 검사를 피하기 위해 "시뮬레이션 유형"을 완료했습니다.

동적 유형 언어는 복잡한 앱이 아닌 OS 스크립트 및 빠른 작은 앱에 적합합니다.

요약 : 내가 "약한 유형"또는 "동적 유형"프로그래밍 언어, 또는 복잡한 비즈니스 응용 프로그램에 대한 "강한 유형"프로그래밍 언어 사이에서 선택해야하는 경우, 나는 선택 "강한 유형"프로그래밍 언어 .

한 걸음 물러서서 동적 타이핑이 문제를 일으키는 시점을 고려하는 것이 비용이라고 생각합니다.

한 가지 경우는 코드 분기가 전혀 테스트되지 않았지만 테스트되지 않은 솔직한 코드는 동적 타이핑 사용 여부에 관계없이 버그가있을 수 있습니다.

그러나 또 다른 미묘한 문제는 불완전한 대체 가능성입니다.

유형이 완전히 잘못 된 경우 특정 코드 경로를 사용하지 않으면 신속하게 감지 될 수 있습니다.

반면에 유형이 불완전한 대체 인 경우 코드는 대부분 작동하지만 나중에는 감지되지 않는 미묘한 방식으로 중단 될 수 있습니다.

프로그래밍에서 가장 일반적인 유형 중 두 가지는 숫자와 문자열입니다. 많은 역동적 인 언어들에서 그들은 서로를 대체하는 불완전한 대안입니다. javascript 또는 php에서 문자열이 예상되는 숫자를 제공하거나 그 반대로 프로그램을 실행하면 오류가 발생하지 않고 실행되지만 다소 작은 방식으로 오작동 할 수 있습니다.

파이썬은 특정 문제, 숫자 및 문자열이 서로를 대체 할 수는 없으며 다른 것이 예상되는 곳을 사용하려고하면 일반적으로 빠른 실패로 이어질 것임을 피했습니다.

그러나 불완전한 가능성 문제를 완전히 피하지는 못했습니다. 서로 다른 유형의 숫자는 서로를 완벽하게 대체 할 수 없으므로 다른 유형의 시퀀스도 가능합니다.

내가 여기에 얻는 것은 정적 및 동적 입력의 이점과 비용을 일반적인 방식으로 비교할 수 없다고 생각한다는 것입니다. 왜냐하면 이점과 비용이 언어의 정적 또는 동적 입력의 특정 변형에 달려 있다고 생각하기 때문입니다. 사용합니다.