정적 및 동적 유형의 언어를 다른 유형의 작업에 대한 다른 도구로 볼 수 있습니까?

9

그렇습니다. 비슷한 질문이 있지만 항상 '어느 쪽이 더 낫다'는 것을 목표로합니다.

나는 주로 JavaScript에서 개발자로 올라 와서 정적으로 유형이 지정된 언어로 글을 쓴 경험이 없기 때문에 묻습니다.

그럼에도 불구하고 필자는 낮은 수준의 코드에서 까다로운 작업을 처리하는 데 C를 배우는 데 가치가 있음을 분명히 알 수 있습니다 (컴파일러 수준에서 정적 대 동적과 관련이 있다고 가정합니다). Java와 C #을 사용하는 것이 파이썬과 같은 것이 더 합리적인 성능 이외의 특정 프로젝트 컨텍스트 (특정 유형의 동적 데이터 집약적 작업입니까?)가 있는지 여부입니다.

dynamic-typing static-typing

— 에릭 레펜
소스

5

대답은 "예"입니다. 각 언어 유형 (실제로 각 언어)에는 강점과 약점이 있으므로 다른 작업보다 일부 작업에 더 적합합니다.

— ChrisF

C를 예를 들어 사용하는 것이 흥미 롭습니다. 왜냐하면 가장 약한 유형의 언어이기 때문에 정형화 된 유형이라고 생각할 수 있습니다. 형식 시스템으로 인해 C가 빠르지 않으며 컴파일 할 때 형식 검사가 수행됩니다. 보안 조치가 거의 없거나 전혀 없기 때문에 C는 빠릅니다. 네이티브 바이너리로 컴파일되기 때문입니다.

— sara

10

물론 이죠
동적 타이핑은 모든 것을 단일 유형으로 취급하려는 경우 확실한 이점이 있습니다. 직렬화 / 직렬화는 고전적인 예 중 하나입니다. 이것이 바로 웹 프로그래밍이 동적 유형의 스크립팅 언어로 수행되는 이유입니다. 모든 종류의 데이터를 문자열로 변환하거나 문자열로 변환하는 작업이 많은 작업에 적합합니다.

반면에 응용 프로그래밍의 경우 정적 언어는 모든 것을 하나의 단일 유형으로 취급하는 것이 종종 요구되는 것은 아니기 때문에 훨씬 더 효과적 입니다. 종종 데이터 자체를 나타내며 다른 유형으로 자주 변환되지 않는 효율적인 데이터 구조를 원합니다. 이로 인해 동적 타이핑 기능이 이점 대신 단점이되므로 응용 프로그램이 거의 정적으로 유형이 지정된 언어로 작성됩니다.

— 메이슨 휠러
소스

3

@ 에릭 : 나는 심지어 그렇게 말할 것입니다. 개발 과정에서 상황이 바뀝니다. 요구 사항이 변경되거나 요구 사항을 올바르게 구현하지 않았으므로 코드를 업데이트해야합니다. 한 가지만 변경하고 결과 컴파일러 오류를 사용하여 변경해야하는 다른 모든 항목을 찾을 수있는 위치를 표시하면 해당 기술을 사용할 수없는 언어에서는 편의성과 개발 속도가 크게 향상됩니다. 이것이 동적 언어로 개발 된 복잡한 앱을 보지 못하는 이유 중 하나입니다.

— 메이슨 휠러

9

@Mason Wheeler : 아주 좋은 대답입니다. + 1 정적 타입 검사는 컴파일러가 타입 검사 정확성을 검사함으로써 버그를 조기에 발견하는 데 도움이된다고 덧붙입니다. 예를 들어 어제 200 줄 Ruby 프로그램을 디버깅했는데, 프로그램을 실행해서 만 감지 할 수있는 유형과 관련된 두 가지 버그가있었습니다. 100000 라인 프로젝트에서 어떤 일이 일어나는지 생각하고 싶지 않습니다. 따라서 동적 타이핑은 더 많은 유연성을 제공하며, 이는 컴파일시 특정 버그를 찾을 수없는 가격으로 설명 된 컨텍스트에서 유용합니다. 따라서 정적으로 입력되는 것은 효율성뿐만 아니라 정확성과 관련이 있습니다.

— Giorgio

1

@MasonWheeler 2 년 동안 나중에 협상 한 것보다 훨씬 많은 C #과 Java가 이제 몇 가지에 동의하지 않습니다. 복잡한 웹 앱은 전적으로 동적 언어로 수행됩니다. 즉시 볼 수있는 변경을 수행 할 수 있으면 컴파일 대 실행 시간은 의미가 없습니다. 그리고 데이터에 대한 데이터가 처음부터 끊임없이 바뀌지 않아야하는 OOP에 의해 구동되는 언어보다 형식에 대한 모든 소란이 절차 적 언어보다 훨씬 더 의미가 있다는 의견을 개발했습니다.

— Erik Reppen

1

@Erik : * wince * 우선, Java의 개념으로 정적 타이핑을 판단하는 것은 Pinto의 개념으로 자동차를 판단하는 것과 같습니다. 둘째, 변경 사항이 "즉시 표시"될 수있는 것은 정의상 매우 복잡한 프로그램이 아닙니다. 최신 하드웨어를 사용하더라도 복잡한 프로그램은 코드를 준비하는 데 상당한 시간이 걸리기 때문입니다. 또는 준비하는 JIT 컴파일러). 가장 인상적인 웹 응용 프로그램조차도 매우 복잡한 데이터베이스로 뒷받침되는 매우 간단한 프로그램 인 경향이 있습니다. 이는 완전히 다른 문제입니다.

— 메이슨 휠러

1

복잡한 추상화를 할 수있는 능력은 정적 대 동적 유형 시스템과 직교하며 속도와 직교합니다. 거기에는 정적 타입 시스템이있어 엄청나게 강력한 추상화를 가능하게합니다. 변경 사항이 즉시 표시되는 것도 유형 시스템과 무관합니다. 정적으로 유형이 지정된 언어에 대한 통역사를 구축 할 수 있습니다.

— Rufflewind

4

내가 보는 방식은 정적으로 유형이 지정된 언어 내에서 자연스럽게 일할 수 있다면 정적 입력이 방법입니다. 일반적으로 형식 시스템의 목적은 정의되지 않은 의미 체계와 같은 작업을 수행하지 못하게하는 것 (string) "hello" + (bool) true입니다. 이러한 작업을 수행하지 못하게하는 추가적인 안전 수준을 갖추면 광범위한 단위 테스트 없이도 코드의 버그를 예방할 수 있습니다 . 즉, 타입 안전성은 코드의 의미 론적 정확성에 대한 또 다른 수준의 신뢰를 제공합니다.

그러나 타입 시스템은 제대로 이해하기가 매우 어렵습니다. 나는 이 글을 쓰는 시점에 본질 상 완벽한 타입 시스템 이 없다고 생각 합니다. ( "완벽한 유형 시스템"이란 엄격한 코드 시스템을 의미하며, 자세한 코드 주석이 필요하지 않으며, 오 탐지 유형 오류가 발생하지 않으며 프로그래머가 이해하기 쉬운 유형 오류입니다.) 존재하는 정말 좋은 유형의 시스템을 이해하기 어렵습니다. Haskell을 배울 때 올바른 코드처럼 보이는 것을 쓰려고 할 때 발생하는 모호한 유형 오류의 수를 알려줄 수 없습니다. 일반적으로 코드는 실제로 정확하지는 않지만 (타입 시스템에 유리한 점), 많은 시간이 걸렸습니다.컴파일러의 오류 메시지를 이해하여 근본적인 문제를 해결할 수 있습니다. OO 언어에서는 결국 "이 인수는 공변량이 아닌 입력 유형과 반 변형 이어야합니다 !"라고 생각하거나 유형 시스템의 경계를 벗어나기 위해 타입 캐스트로 되돌릴 가능성이 높습니다. 타입 시스템은 생각보다 훨씬 까다로울 수 있습니다.

가치있는 것은 좋은 타입의 시스템을 구현하기가 어렵다는 점이 Gilad Bracha 가 Newspeak에 플러그 가능한 타입 시스템 지원을 포함 하도록 동기를 부여한 것의 일부라는 것을 이해하고 있습니다.

— 아이 단 컬리
소스

WRT 단위 테스트에 동의합니다. 당신은 항상 사람들이 "좋은 단위 테스트를한다면 타입 정확성을 확인할 수 있습니다"라고 말합니다. 다이나믹 타이핑이 항상 좋은 것이라고 Paul Graham (강력한 믿음이라고 믿는 사람)이 수동으로 컴파일러 작업을 수행하는 언어가 결함이있는 언어라고 말하는 방식을 항상 상기시켜줍니다. Sorta는 당신을 멈추게하고 생각하게합니다 ...

— Mason Wheeler

나는 동적으로 유형이 지정된 언어의 '위험'에 대한 많은 우려가 우리 가이 물건을 쓰는 방법을 고려하지 못한다고 생각합니다. 많은 Python과 JS는 콘솔 스타일로 작성 될 수 있습니다. 스크류 컴파일 대 런타임, 지금 시도해보고 무슨 일이 일어나는지 볼 수 있습니다. 그러나 당신이 한 가지 좋은 점에 있다고 생각합니다. IE6 또는 7이 예상치 못한 일을하는 동안 IE6 또는 7이 예상치 못한 코드를 혼동하는 경우보다 클라이언트 측 웹 개발에서 더 미친 짓을하지는 않습니다. 더 일반적인 방식으로 빠는.

— Erik Reppen

@ mason-wheeler 불일치 유형은 사소한 오류이며 동적 언어가 유형을 확인하지 않고 런타임에만 있습니다. 필자의 경험에 따르면 대부분의 정적 언어는 동일한 수준의 단위 테스트 범위를 가지며 컴파일러에서 미리 유형을 검사하여 테스트를 잃지 않으며 동적 언어는 유형을 확인하기 위해 특정 테스트를 추가 할 필요가 없습니다. , 런타임 시스템은 유형을 확인합니다. 단위 테스트에서 메소드를 다루면 유형을 검사합니다.

— jbtule

4

그것들은 다른 도구이지만 성능에 의한 것은 아닙니다. 복잡성 에 관한 모든 것 .

동적 언어는 일반적으로 최대의 유연성을 목표로하며 유효성 검사가 부족하고 일종의 보증을 제공합니다. 그런 다음 소규모 프로그램에서는 매우 강력하지만 대규모 프로그램 (복잡성)을 유지하는 것은 거의 불가능합니다.

정적 언어는 일반적으로 최대 유효성 검사를 목표로합니다. 첫 번째 목표는 일반적으로 가능한 빨리 오류 (또는 버그)를 포착하는 것입니다. 유효성 검사에 대해 많은 보증이 이루어집니다. 그런 다음 배우고 시작하기는 어렵지만 프로그램이 커질수록 훨씬 적은 비용으로 더 나은 프로그램 유효성 검사를 제공합니다 (코딩 노력).

결과적으로 동적 언어는 일반적으로 동적 웹 페이지, 웹 브라우저 DSL (브라우저 응용 프로그램이 아님) 또는 쉘 스크립팅과 같은 작은 (매우 작은) 프로그램에 적합합니다. 정적 언어는 시스템 프로그래밍이나 다른 것들에 더 적합합니다.

위의 설명은 매우 순수한 동적 또는 정적 언어에 관한 것입니다. 대부분의 실제 언어는 그들 사이에 있으며 다양한 특성을 보여줍니다.

자세한 내용은 여기를 참조하십시오 : https://softwareengineering.stackexchange.com/a/105417/17428

— 어닐
소스

1

"동적 언어는 일반적으로 작은 (매우 작은) 프로그램에 적합합니다.": 제 경험상 중형 응용 프로그램에도 동적 언어를 사용할 수 있습니다 (물론 큰 응용 프로그램에 성공적으로 사용하는 사람들도 있습니다). 코드베이스가 커질수록 정적 언어에서 제공하는 정적 검사에서 더 많은 이익을 얻을 수 있다는 데 동의합니다.

— 조르지오

2

@Giorgio 글쎄, 아마도 정적 유효성 검사에 중독되어 있기 때문일 수 있습니다. 그것은 나에게 너무 달콤하고 작은 규모에서도 문자 그대로 없이는 살 수 없습니다 : p

— Eonil

나는 정적 언어의 장점을 보았습니다 (그리고 당신의 대답을 상향 조정했습니다). 최근에는 Python 및 Common Lisp를 사용하고 있으며 실제로 깨끗한 디자인을 사용하면 특히 Python에서 충분한 테스트를 작성하면 좋은 결과를 얻을 수 있음을 인정합니다. 이러한 언어는 프로토 타입을 제작하는 데 매우 효과적이며 생산 코드로 쉽게 전환 할 수 있습니다. 그러나 더 복잡한 프로젝트의 경우 최대한 많은 도움을 받고자하므로 정적 언어를 선호합니다.

— 조르지오

1

저는 현재 정적 유형 언어 (C # 및 F #)로 프로그래밍하지만 동적 언어 (Smalltalk, Ruby)로 프로그래밍하는 것을 좋아합니다. 사람들이 유형을 시행 할 때보 다 언어에 대해 더 많은 유형과 관련이있는 많은 장단점이 있습니다. 예를 들어, 동적 언어는 일반적으로 더 깔끔하고 간결한 구문을 갖지만 형식 유추 시스템이있는 F # 및 OCaml은 동적 언어만큼 구문이 깨끗합니다. 정적 타이핑을 사용하면 실제 자동 리팩토링과 자동 완성 기능이 있지만 데이터베이스의 전체 소스 코드와 개별적으로 컴파일 된 스몰 토크가있는 스몰 토크는 실제로 자동으로 리팩토링을 수행 한 첫 번째 언어였으며 훌륭하게 작동했습니다. 궁극적으로 오늘날의 동적 언어 및 정적 언어는 오늘날 형식 안전이며, 이는 형식 시스템의 가장 중요한 측면입니다.

— jbtule
소스

나는 때때로 정적 타이핑이 언어를 다소 유연하게 만드는 방정식의 작은 부분 일 것이라고 생각했습니다. 나는 또한 내가 깨닫기 시작한 것은 많은 개발자들이 오버로드 연산자와 같이 터무니없이 위험한 일을 자유로이 지배하기보다는 편안한 레일 세트를 선호한다는 것입니다. VS는 때로는 강아지를 쫓고 싶지만 F #에 대해 궁금한 점이 많았습니다. 나는 이것이 당신이 더 포괄적 인 유형으로 암시 적으로 캐스팅 할 수있는 C # 일 이상이라고 생각합니다.

— Erik Reppen

@erik, 오, 그렇습니다. 타이핑과 var를 의미하는 것 이상입니다. F # 형식 유추

— jbtule

-1

이제 2015 년에 대화에 흥미로운 스 니펫이 추가되었습니다.

엔터프라이즈 백엔드 세계 의 상당 부분이 Java (엄격한 정적) 대신 Python (동적)을 고려하거나 사용하기 시작했습니다.
엔터프라이즈 프론트 엔드 세계는 TypeScipt : Javascript 의 유형 확장 인 AngularJS v2와 같은 것을보고 있습니다.

따라서 백엔드 사람들은 불필요한 타이핑의 직선 자켓에 지쳤으며, 프론트 엔드 사람들은 다이내믹 타이핑의 혼란에 질려 있습니다.

꽤 아이러니 : 중간에 만나거나 마감 기한의 소닉 붐으로 서로를 뛰어 넘을 지 궁금합니다 ...? ;)

— 코넬 마손
소스

증거를 제공하지 않으면 최악의 경우 백엔드 세계가 Go로 전환되고 있다고 주장 하지만 동적 스크립트는 금지합니다. 정적 프로그래밍 언어가 항상 많은 의식을 가지고 있다는 신화는 오랫동안 더 강력한 추론 시스템과 견고한 REPL 구현으로 논쟁의 여지가 있습니다

— Den

대규모로 사용중인 동적 유형 백엔드가 많이 있습니다. Django는 특히 저널리즘에서 매우 유명하며 NYT, Guardian 및 Washington Post의 백엔드를 운영하고 있습니다. Walmart가 노드에서 실행 중입니다. 유일한 신화는 정적 유형이 없으면 스케일에 쓸 수 없다는 아이디어입니다. 그리고 내가 겪었던 일부 Java 레거시 코드 기반 재해에 대해 생각한 후, 편안하게 작업하는 사람들은 정적이든 동적이든 상관없이 더 나은 방법이라고 생각합니다.

— Erik Reppen

실제로, 나는 자바 프로젝트가 아닌 대기업 프로젝트에 숙련 된 파이썬 팀을 갖고 싶습니다. 내 입장을 분명히하기 위해 위의 답변을 평가했습니다.

— Cornel Masson

실제로, 나는 큰 자바 프로젝트보다는 숙련 된 파이썬 팀을 대기업 프로젝트에 사용하고 싶습니다. 명확히하기 위해 : 나는 클라이언트 기반, 산업 네트워크 및 일반 연구에서보고있는 추세에 대한 관찰로 위의 답변을 게시했습니다. 전통적으로 엄격한 백엔드는 엄격 성이 떨어지고 프론트 엔드가 느슨합니다. "올바른"(있는 경우)에 대한 의견조차도 아닙니다. 아마도 아이러니가 사라질 것입니다.

— Cornel Masson