사람들이 동적 언어에서 그토록 매력적이라고 생각하는 것은 무엇입니까? [닫은]
요즘 모두가 다이나믹하고 컴파일되지 않은 악 대차에 뛰어 드는 것 같습니다. 저는 대부분 컴파일 된 정적 유형 언어 (C, Java, .Net)로만 작업했습니다. 동적 언어에 대한 경험은 ASP (Vb Script), JavaScript 및 PHP와 같은 것입니다. 이러한 기술을 사용하면 동적 언어를 생각할 때 입에 나쁜 맛이 남았습니다. 맞춤법이 틀린 변수 이름 및 잘못된 유형의 값을 변수에 할당하는 것과 같이 일반적으로 컴파일러에 의해 포착되었을 수있는 것은 런타임까지 발생하지 않습니다. 그런 다음에도 새 변수를 만들고 일부 기본값을 할당하기 때문에 오류가 발생하지 않을 수 있습니다. 또한 변수에 명시 적 유형이 없기 때문에 동적 언어에서 인텔리 센스가 잘 작동하는 것을 본 적이 없습니다.
제가 알고 싶은 것은 사람들이 동적 언어에 대해 그토록 매력적이라고 생각하는 것은 무엇입니까? 다이나믹 언어로 할 수있는 일의 측면에서 할 수 없거나 컴파일 된 언어로하기 어려운 주요 이점은 무엇입니까? 오래 전에 우리가 런타임 예외를 던지는 컴파일되지 않은 ASP 페이지와 같은 것은 나쁜 생각이라고 결정한 것 같습니다. 이러한 유형의 코드가 왜 부활합니까? 그리고 적어도 Ruby on Rails가 10 년 전에 ASP로 할 수 없었던 어떤 것과도 다르게 보이는 이유는 무엇입니까?
그 이유는 사람들이 매우 제한적이고 표현력이없는 유형 시스템을 가진 정적으로 유형화 된 언어에 익숙하기 때문이라고 생각합니다. 이들은 Java, C ++, Pascal 등과 같은 언어입니다.보다 표현적인 유형 시스템과 더 나은 유형 추론 (예를 들어 Haskell에서와 같이 어느 정도 SQL에서도)의 방향으로가는 대신 일부 사람들은 모든 "유형"정보를 머리 (및 테스트)에 포함하고 정적 유형 검사를 모두 제거합니다.
이것이 결국 당신을 사게하는 것은 불분명합니다. typechecking에 대한 오해가 많이 있습니다. 제가 가장 흔히 접하는 것은이 두 가지입니다.
오류 : 동적 언어는 덜 장황합니다. 오해는 유형 정보가 유형 주석과 같다는 것입니다. 이것은 완전히 사실이 아닙니다. 우리 모두는 타입 어노테이션이 성가시다는 것을 알고 있습니다. 기계는 그런 것들을 알아낼 수 있어야합니다. 사실, 그것은 현대 컴파일러에서 수행됩니다. 다음은 Haskell의 두 줄에있는 정적으로 형식화 된 QuickSort입니다 ( haskell.org ).
qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
다음은 동적으로 입력 된 LISP의 QuickSort입니다 ( swisspig.net 에서 제공 ) :
(defun quicksort (lis) (if (null lis) nil
(let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
(append (quicksort (remove-if-not fn r)) (list x)
(quicksort (remove-if fn r))))))
Haskell 예제는 정적으로 입력 된 가설을 위조 하므로 verbose . LISP 예제는 자세한 가설을 위조 하므로 정적으로 입력 됩니다. 타이핑과 자세한 정도 사이에는 어떤 의미도 없습니다. 당신은 그것을 당신의 마음에서 안전하게 제거 할 수 있습니다.
오류 : 정적으로 형식화 된 언어는 해석이 아니라 컴파일되어야합니다. 다시 말하지만 사실이 아닙니다. 정적으로 입력 된 많은 언어에는 인터프리터가 있습니다. Scala 인터프리터, Haskell 용 GHCi 및 Hugs 인터프리터가 있습니다. 물론 SQL은 제가 살아있는 것보다 더 오랫동안 정적으로 입력되고 해석되었습니다.
아시다시피, 역동적 인 군중은 자신이하는 일에 대해 신중하게 생각할 필요가없는 자유를 원할 것입니다. 소프트웨어가 정확하지 않거나 견고하지 않을 수 있지만 반드시 그럴 필요는 없습니다.
개인적으로 형식 안전을 포기하고 일시적인 자유를 구입하려는 사람들은 자유도 형식 안전도받을 자격이 없다고 생각합니다.
컴파일러가하는 일을 대체하기 위해 단위 테스트에서 10 배의 코드 커버리지를 작성해야한다는 것을 잊지 마십시오.
나는 거기에 있었고, 동적 언어로 그렇게했고, 전혀 이점이 없다고 생각합니다.
다른 사람들의 반응을 읽을 때 동적 언어에 대한 세 가지 주장이 다소있는 것 같습니다.
1) 코드가 덜 장황합니다. 나는 이것이 유효하지 않다고 생각합니다. 일부 동적 언어는 일부 정적 언어보다 덜 장황합니다. 그러나 F #은 정적으로 입력되지만 정적 입력은 코드를 많이 추가하지 않습니다. 하지만 암시 적으로 형식화되어 있지만 이는 다릅니다.
2) "내가 가장 좋아하는 동적 언어 X에는 내가 가장 좋아하는 기능적 기능 Y가 있으므로 동적이 더 좋습니다." 기능과 동적을 혼동하지 마십시오 (왜 이것이 말해야하는지 이해할 수 없습니다).
3) 동적 언어에서는 결과를 즉시 볼 수 있습니다. 뉴스 : Visual Studio (2005 년부터)에서도 C #을 사용할 수 있습니다. 중단 점을 설정하고 디버거에서 프로그램을 실행하고 디버깅하는 동안 프로그램을 수정하면됩니다. 나는 항상 이것을하고 완벽하게 작동합니다.
저 자신은 정적 타이핑을 강력하게 옹호합니다. 한 가지 주된 이유는 유지 관리입니다. 나는 거기에 자바 스크립트의 몇 10K 라인 시스템을 가지고 있고, 어떤 I는 (존재하지 않는) 컴파일러가 변수가 엉망 이름 바꾸기가 무엇인지 말하지 때문에 반나절처럼 걸릴 싶지 리팩토링. 그리고 그것은 내가 직접 작성한 코드이며 IMO도 잘 구성되어 있습니다. 나는 다른 누군가가 작성한 동등한 동적 시스템을 담당하는 작업을 원하지 않을 것입니다.
나는 이것에 대해 엄청나게 비추천받을 것이라고 생각하지만 나는 기회를 잡을 것입니다.
VBScript는 다른 버전의 VB와 비교하지 않는 한 짜증납니다. PHP는 너무 자란 템플릿 언어라는 점을 명심하는 한 괜찮습니다. 현대 자바 스크립트는 훌륭합니다. 정말. 엄청난 재미. "DHTML"태그가 붙은 스크립트를 멀리하십시오.
런타임 오류를 허용하지 않는 언어를 사용한 적이 없습니다. IMHO, 그것은 대체로 붉은 청어입니다 : 컴파일러는 모든 오타를 포착하지 않으며 의도를 검증하지도 않습니다. 명시 적 유형은 명시 적 유형이 필요할 때 유용하지만 대부분의 경우 그렇지 않습니다. 여기서 질문을 검색 generics하거나 서명되지 않은 유형을 사용하는 것이 인덱스 변수에 적합한 선택인지 여부 에 대한 질문을 검색합니다. 대부분의 경우이 항목은 방해가되며 시간이있을 때 사람들이 손을 움직일 수있게합니다. .
그러나 나는 당신의 질문에 정말로 대답하지 않았습니다. 동적 언어가 매력적인 이유는 무엇입니까? 잠시 후 코드 작성이 지루해지고 알고리즘을 구현하고 싶기 때문입니다. 당신은 이미 모든 것을 펜으로 작업하고 잠재적 인 문제 시나리오를 도표화하고 해결할 수 있음을 증명했으며 남은 것은 20 줄의 구현을 코딩하는 것뿐입니다 ... 그리고 컴파일 할 수 있도록 200 줄의 상용구를 작성하는 것입니다. . 그럼 당신은 당신이 작업하는 타입 시스템은 당신이 실제로 무슨 일을하는지 반영하지 않는다는 것을 깨닫게하지만, 다른 사람이 당신이 무엇을 매우 추상적 인 생각이 수 일을 할, 당신은 오래 전에 그렇게 knicknack의 미세 조정의 삶을 위해 프로그램을 포기했습니다 가상의 탐정 애드리안 몽크조차도 부끄럽게 만들 것이라는 강박 적입니다.
당신의 그
반죽 가서
시작 동적 언어에 심각하게보고있다.
저는 정적으로 형식화 된 C #의 고통에 완전히 푹 빠진 풀 타임 .Net 프로그래머입니다. 그러나 저는 현대 JavaScript를 좋아합니다.
일반적으로 동적 언어를 사용하면 정적으로 입력 된 언어보다 의도를 더 간결하게 표현할 수 있다고 생각합니다 . 많은 경우에 표현하려는 구성 요소가 무엇인지 정의하는 데 시간과 공간을 덜 소비하기 때문입니다.
동적 언어의 여러 클래스도 있다고 생각합니다. VBScript에서 고전적인 ASP 페이지를 작성하는 것으로 돌아가고 싶지 않습니다. 유용하게 사용하려면 동적 언어가 핵심에서 일종의 수집, 목록 또는 연관 구성을 지원하여 객체 (또는 객체에 전달되는 것)를 표현하고 더 복잡한 구성을 만들 수 있도록해야한다고 생각합니다. (어쩌면 우리 모두 LISP로 코드를 작성해야 할지도 몰라요 ... 농담입니다 ...)
.Net 서클에서 동적 언어는 VBScript 및 / 또는 JavaScript와 관련되어 있기 때문에 나쁜 평가를받습니다. VBScript는 Kibbee가 언급 한 여러 이유 때문에 악몽으로 회상 될뿐입니다. 누구나 CLng를 사용하여 VBScript에서 유형을 적용하여 32 비트 정수에 대해 충분한 비트를 얻었음을 기억합니다. 또한 JavaScript는 여전히 모든 브라우저에 대해 다른 방식으로 작성된 드롭 다운 메뉴의 브라우저 언어로 간주됩니다. 이 경우 문제는 언어가 아니라 다양한 브라우저 개체 모델입니다. 흥미로운 점은 C #이 성숙할수록 더 역동적으로 보이기 시작한다는 것입니다. 저는 Lambda 식, 익명 객체 및 유형 추론을 좋아합니다. 매일 JavaScript처럼 느껴집니다.
다음은 Haskell의 두 줄에있는 정적으로 형식화 된 QuickSort입니다 (haskell.org에서 제공).
qsort [] = [] qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)다음은 동적으로 입력 된 LISP의 QuickSort입니다 (swisspig.net에서 제공).
(defun quicksort (lis) (if (null lis) nil (let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x)))) (append (quicksort (remove-if-not fn r)) (list x) (quicksort (remove-if fn r))))))
나는 당신이 여기에서 선택한 언어로 일을 편향시키고 있다고 생각합니다. Lisp는 악명 높게 괄호가 무겁습니다. Haskell과 더 가까운 것은 Python입니다.
if len(L) <= 1: return L
return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])
여기 에서 파이썬 코드
나에게 동적 언어의 장점은 Ruby의 블록 및 Python의 목록 이해와 같은 코드 및 기능적 기술 이 적기 때문에 코드를 훨씬 더 쉽게 읽을 수 있다는 것 입니다.
그러나 나는 컴파일 시간 검사 (오타 발생)와 IDE 자동 완성을 놓칩니다. 전반적으로, 적은 양의 코드와 가독성이 저에게 보상을줍니다.
또 다른 장점은 언어 의 일반적으로 해석되거나 컴파일되지 않은 특성입니다. 일부 코드를 변경하고 즉시 결과를 확인하십시오. 개발하는 동안 정말 시간을 절약 할 수 있습니다.
마지막으로, 콘솔을 실행 하고 이전에 사용한 적이없는 클래스 나 메서드와 같이 확실하지 않은 것을 시도해보고 어떻게 작동하는지 확인할 수 있다는 사실이 마음에 듭니다. 콘솔에는 많은 용도가 있으며 알아 내도록 남겨 두겠습니다.
동적 언어에 대한 귀하의 주장은 완벽하게 유효합니다. 그러나 다음 사항을 고려하십시오.
- 동적 언어는 컴파일 할 필요가 없습니다 . 실행 만하면됩니다. 대부분의 경우 애플리케이션을 다시 시작하지 않고 런타임에 파일을 다시로드 할 수도 있습니다.
- 동적 언어는 일반적으로 덜 장황하고 읽기 쉽습니다 . 정적 언어로 구현 된 주어진 알고리즘이나 프로그램을 살펴본 다음 Ruby 또는 Python에 해당하는 것과 비교 한 적이 있습니까? 일반적으로 코드 줄이 3 배 감소하는 것을보고 있습니다. 동적 언어에서는 많은 스캐 폴딩 코드가 필요하지 않습니다. 즉, 최종 결과가 더 읽기 쉽고 실제 문제에 더 집중됩니다.
- 타이핑 문제에 대해 걱정하지 마십시오 . 동적 언어로 프로그래밍 할 때 일반적인 접근 방식은 타이핑에 대해 걱정할 필요가 없습니다. 대부분의 경우 올바른 종류의 인수가 메서드에 전달됩니다. 그리고 때때로 누군가는 그냥 우연히 작동하는 다른 종류의 논쟁을 사용할 수 있습니다. 일이 잘못되면 프로그램이 중지 될 수 있지만 몇 가지 테스트를 수행 한 경우에는 거의 발생하지 않습니다.
저도 처음에는 안전한 정적 타이핑 세계에서 벗어나는 것이 약간 무섭다는 것을 알았습니다.하지만 저에게는 장점이 단점보다 훨씬 큽니다.
나는 동적 유형 언어에 대한 "새로운 발견 된 사랑"이 특정 동적 언어의 인기 증가보다 정적으로 유형화 된 언어가 더 나은지 최악인지와 관련이 없다고 생각합니다 . Ruby on Rails는 분명히 동적 언어의 부활을 야기하는 큰 현상이었습니다. 레일을 매우 인기있게 만들고 정적 캠프에서 많은 변환을 생성 한 것은 주로 매우 간결하고 DRY 코드 및 구성이었습니다. 많은 XML 구성이 필요한 Java 웹 프레임 워크와 비교할 때 특히 그렇습니다. 많은 자바 프로그래머 (스마트 한 프로그래머)가 전환되었고 일부는 루비와 기타 동적 언어를 전파하기도했습니다. 저에게는 세 가지 고유 한 기능으로 Ruby 또는 Python과 같은 동적 언어가 더 간결해질 수 있습니다.
- 미니멀리즘 구문-큰 문제는 유형 주석이 필요하지 않지만 언어 설계자가 처음부터 간결하게 언어를 설계했다는 것입니다.
- 인라인 함수 구문 (또는 람다)-인라인 함수를 작성하고 변수로 전달하는 기능은 여러 종류의 코드를 더 간단하게 만듭니다. 특히 이것은 목록 / 배열 작업에 해당됩니다. 이 아이디어의 뿌리는 분명히 LISP였습니다.
- 메타 프로그래밍-메타 프로그래밍은 레일을 틱하게 만드는 중요한 부분입니다. 라이브러리의 클라이언트 코드를 훨씬 더 간결하게 만들 수있는 새로운 코드 리팩토링 방법이 생겼습니다. 이것은 또한 LISP에서 비롯됩니다.
이 세 가지 기능 모두 동적 언어에만 국한되지는 않지만 오늘날 널리 사용되는 정적 언어 인 Java 및 C #에는 확실히 존재하지 않습니다. C #이 대리자에서 # 2를 가지고 있다고 주장 할 수 있지만, 목록 작업과 같이 널리 사용되지는 않는다고 주장합니다.
고급 정적 언어에 관해서는 ... Haskell은 멋진 언어입니다. # 1과 # 2가 있습니다. 그리고 # 3은 없지만 유형 시스템이 너무 유연해서 메타의 부족함을 찾지 못할 것입니다. 제한적입니다. 컴파일 타임에 언어 확장을 사용하여 OCaml에서 메타 프로그래밍을 할 수 있다고 믿습니다. Scala는 매우 최근에 추가되었으며 매우 유망합니다. .NET 캠프를위한 F #. 그러나 이러한 언어의 사용자는 소수이므로 프로그래밍 언어 환경의 이러한 변화에 실제로 기여하지 않았습니다. 사실 Ruby의 인기가 다른 동적 언어 외에도 Haskell, OCaml, Scala, F #과 같은 언어의 인기에 긍정적 인 영향을 미쳤다고 생각합니다.
개인적으로, 나는 당신이 사용했던 대부분의 "동적"언어가 일반적으로 언어의 형편없는 예일 뿐이라고 생각합니다.
나는 방법 C 또는 Java보다 파이썬에서 생산성, 그리고 당신이 편집 - 컴파일 - 링크 - 실행 춤을 할 필요가 있기 때문이다. Objective-C에서 생산성이 높아지고 있지만 아마도 프레임 워크 때문일 것입니다.
말할 필요도없이, 저는 PHP보다 이러한 언어에서 더 생산적입니다. 지옥, PHP보다는 Scheme 또는 Prolog로 코딩하는 것이 좋습니다. (하지만 최근에 나는 다른 어떤 것보다 프롤로그를 더 많이하고 있으니, 그것을 소금과 함께 가져 가세요!)
동적 언어에 대한 나의 감사는 그것이 얼마나 기능적인가 와 매우 관련 이 있습니다. 파이썬의 목록 이해력, 루비의 클로저, 자바 스크립트의 프로토 타입 객체는 모두이 언어의 매우 매력적인 측면입니다. 모두는 또한 일류 기능을 갖추고 있습니다. 다시는없이 사는 것을 볼 수 없습니다.
PHP와 VB (스크립트)를 같은 방식으로 분류하지 않습니다. 나에게 그것들은 당신이 제안하는 모든 동적 타이핑 결점을 가진 대부분 명령형 언어입니다.
물론 컴파일 시간이 없기 때문에 동일한 수준의 컴파일 시간 검사를 얻지는 못하지만 정적 구문 검사 도구가 시간이 지남에 따라 적어도 부분적으로는 그 문제를 해결하기 위해 발전 할 것으로 예상합니다.
동적 언어에 대해 지적 된 장점 중 하나는 코드를 변경하고 계속 실행할 수 있다는 것입니다. 다시 컴파일 할 필요가 없습니다. VS.Net 2008에서 디버깅 할 때 실제로 코드를 변경하고 다시 컴파일하지 않고도 계속 실행할 수 있습니다. 컴파일러와 IDE의 발전으로 동적 언어 사용의 이점과 기타 이점이 사라질 수 있습니다.
아, 비슷한 질문을 올렸을 때이 주제를 보지 못했어요
여기에서 동적 언어에 대해 언급 한 나머지 사람들은 좋은 기능을 제외하고는 모두가 가장 기본적인 것, 즉 메타 프로그래밍을 잊어 버린다고 생각합니다.
프로그램 프로그래밍.
일반적으로 .Net과 같이 컴파일 된 언어로 수행하기는 매우 어렵습니다. 작동하려면 모든 종류의 맘보 점보를 만들어야하며 일반적으로 약 100 배 느리게 실행되는 코드로 끝납니다.
대부분의 동적 언어에는 메타 프로그래밍을 수행하는 방법이 있습니다. 이것이 저를 계속 유지시켜줍니다. 메모리에 모든 종류의 코드를 생성하고이를 제 응용 프로그램에 완벽하게 통합 할 수있는 능력입니다.
예를 들어 Lua에서 계산기를 만들려면 다음과 같이하면됩니다.
print( loadstring( "return " .. io.read() )() )
이제 .Net에서 시도해보십시오.
동적 (쓰레드의 초점 인 것 같기 때문에 타이핑 된) 언어를 좋아하는 주된 이유는 내가 사용한 (작업 환경에서) 언어가 내가 사용한 비 동적 언어보다 훨씬 우수하기 때문입니다. C, C ++, Java 등 ... 모두 실제 작업을 수행하기에는 끔찍한 언어입니다. 동적으로 입력되는 많은 언어로 프로그래밍하기에 자연스러운 암시 적으로 입력 된 언어를보고 싶습니다.
즉, 동적으로 입력되는 언어에서 놀라운 특정 구조가 있습니다. 예를 들어, Tcl에서
lindex $mylist end-2
원하는 인덱스를 나타 내기 위해 "end-2"를 전달한다는 사실은 독자에게 매우 간결하고 분명합니다. 나는 아직 그것을 수행하는 정적으로 형식화 된 언어를 보지 못했다.
나는 이런 종류의 주장이 약간 어리 석다고 생각한다. "맞춤법이 틀린 변수 이름과 변수에 잘못된 유형의 값을 할당하는 것과 같이 일반적으로 컴파일러에 의해 잡혔을 것들은 런타임까지 발생하지 않는다"그렇다. PHP 개발자 나는 런타임까지 잘못 입력 된 변수와 같은 것을 보지 못하지만 런타임은 나에게 2 단계, C ++ (내가 경험 한 유일한 컴파일 된 언어)에서는 연결 및 컴파일 후 3 단계입니다. 
말 그대로 몇 시간이 걸릴 수있는 컴파일 된 언어와는 달리, 코드를 실행할 준비가 될 때까지 저장을 누른 후 몇 초가 걸린다는 것은 말할 것도 없습니다. 이것이 약간 화나게 들리면 미안하지만, 나는 내 코드를 컴파일 할 필요가 없기 때문에 사람들이 나를 2 등급 프로그래머로 대하는 것에 지쳤다.
논쟁은 이것보다 더 복잡합니다 ( 흥미로운 개요를 위해 Yegge의 기사 "Is Weak Typing Strong Enough" 를 읽으십시오 ).
동적 언어에는 오류 검사가 반드시 필요한 것은 아닙니다. C #의 형식 유추가 한 예일 수 있습니다. 같은 방식으로 C와 C ++에는 끔찍한 컴파일 검사가 있으며 정적으로 형식이 지정됩니다.
동적 언어의 주요 장점은 a) 기능 (항상 사용할 필요는 없음) 및 b) Boyd의 반복 법칙입니다 .
후자의 이유는 엄청납니다.
아직 Ruby를 좋아하지는 않지만 동적 언어가 정말 훌륭하고 강력한 도구라는 것을 알게되었습니다.
유형 검사 및 변수 선언이 없다는 생각은 실제로 큰 문제가 아닙니다. 물론 런타임까지 이러한 오류를 포착 할 수는 없지만 숙련 된 개발자에게는 이는 실제로 문제가되지 않으며 실수를했을 때 일반적으로 쉽게 수정됩니다.
또한 초보자는 자신이 쓰고있는 내용을 더주의 깊게 읽어야합니다. PHP를 배우는 것이 내가 실제로 타이핑하는 것에 더주의를 기울 이도록 배웠다는 것을 알고 있습니다. 이것은 컴파일 된 언어에서도 프로그래밍을 향상 시켰습니다.
좋은 IDE는 변수가 "선언"되었는지 여부를 알 수 있도록 충분한 정보를 제공하고 변수가 무엇인지 알 수 있도록 몇 가지 유형 추론을 시도합니다.
The power of what can be done with dynamic languages is really what makes them so much fun to work with in my opinion. Sure, you could do the same things in a compiled language, but it would take more code. Languages like Python and PHP let you develop in less time and get a functional codebase faster most of the time.
And for the record, I'm a full-time .NET developer, and I love compiled languages. I only use dynamic languages in my free time to learn more about them and better myself as a developer..
I think that we need the different types of languages depending on what we are trying to achieve, or solve with them. If we want an application that creates, retrieves, updates and deletes records from the database over the internet, we are better off doing it with one line of ROR code (using the scaffold) than writing it from scratch in a statically typed language. Using dynamic languages frees up the minds from wondering about
- which variable has which type
- how to grow a string dynamically as needs be
- how to write code so that if i change type of one variable, i dont have to rewrite all the function that interact with it
to problems that are closer to business needs like
- data is saving/updating etc in the database, how do i use it to drive traffic to my site
Anyway, one advantage of loosely typed languages is that we dont really care what type it is, if it behaves like what it is supposed to. That is the reason we have duck-typing in dynamically typed languages. it is a great feature and i can use the same variable names to store different types of data as the need arises. also, statically typed languages force you to think like a machine (how does the compiler interact with your code, etc etc) whereas dynamically typed languages, especially ruby/ror, force the machine to think like a human.
These are some of the arguments i use to justify my job and experience in dynamic languages!
I think both styles have their strengths. This either/or thinking is kind of crippling to our community in my opinion. I've worked in architectures that were statically-typed from top to bottom and it was fine. My favorite architecture is for dynamically-typed at the UI level and statically-typed at the functional level. This also encourages a language barrier that enforces the separation of UI and function.
To be a cynic, it may be simply that dynamic languages allow the developer to be lazier and to get things done knowing less about the fundamentals of computing. Whether this is a good or bad thing is up to the reader :)
FWIW, Compiling on most applications shouldn't take hours. I have worked with applications that are between 200-500k lines that take minutes to compile. Certainly not hours.
I prefer compiled languages myself. I feel as though the debugging tools (in my experience, which might not be true for everything) are better and the IDE tools are better.
I like being able to attach my Visual Studio to a running process. Can other IDEs do that? Maybe, but I don't know about them. I have been doing some PHP development work lately and to be honest it isn't all that bad. However, I much prefer C# and the VS IDE. I feel like I work faster and debug problems faster.
So maybe it is more a toolset thing for me than the dynamic/static language issue?
One last comment... if you are developing with a local server saving is faster than compiling, but often times I don't have access to everything on my local machine. Databases and fileshares live elsewhere. It is easier to FTP to the web server and then run my PHP code only to find the error and have to fix and re-ftp.
Productivity in a certain context. But that is just one environment I know, compared to some others I know or have seen used.
Smalltalk on Squeak/Pharo with Seaside is a much more effective and efficient web platform than ASP.Net(/MVC), RoR or Wicket, for complex applications. Until you need to interface with something that has libraries in one of those but not smalltalk.
Misspelled variable names are red in the IDE, IntelliSense works but is not as specific. Run-time errors on webpages are not an issue but a feature, one click to bring up the debugger, one click to my IDE, fix the bug in the debugger, save, continue. For simple bugs, the round-trip time for this cycle is less than 20 seconds.
Dynamic Languages Strike Back
http://www.youtube.com/watch?v=tz-Bb-D6teE
A talk discussing Dynamic Languages, what some of the positives are, and how many of the negatives aren't really true.
Because I consider stupid having to declare the type of the box. The type stays with the entity, not with the container. Static typing had a sense when the type of the box had a direct consequence on how the bits in memory were interpreted.
If you take a look at the design patterns in the GoF, you will realize that a good part of them are there just to fight with the static nature of the language, and they have no reason whatsoever to exist in a dynamic language.
Also, I'm tired of having to write stuff like MyFancyObjectInterface f = new MyFancyObject(). DRY principle anyone ?
Put yourself in the place of a brand new programmer selecting a language to start out with, who doesn't care about dynamic versus staic versus lambdas versus this versus that etc.; which language would YOU choose?
C#
using System;
class MyProgram
{
public static void Main(string[] args)
{
foreach (string s in args)
{
Console.WriteLine(s);
}
}
}
Lua:
function printStuff(args)
for key,value in pairs(args) do
print value .. " "
end
end
strings = {
"hello",
"world",
"from lua"
}
printStuff(strings)
This all comes down to partially what's appropriate for the particular goals and what's a common personal preference. (E.G. Is this going to be a huge code base maintained by more people than can conduct a reasonable meeting together? You want type checking.)
The personal part is about trading off some checks and other steps for development and testing speed (while likely giving up some cpu performance). There's some people for which this is liberating and a performance boost, and there's some for which this is quite the opposite, and yes it does sort of depend on the particular flavor of your language too. I mean no one here is saying Java rocks for speedy, terse development, or that PHP is a solid language where you'll rarely make a hard to spot typo.
I have love for both static and dynamic languages. Every project that I've been involved in since about 2002 has been a C/C++ application with an embedded Python interpret. This gives me the best of both worlds:
- The components and frameworks that make up the application are, for a given release of an application, immutable. They must also be very stable, and hence, well tested. A Statically typed language is the right choice for building these parts.
- The wiring up of components, loading of component DLLs, artwork, most of the GUI, etc... can vary greatly (say, to customise the application for a client) with no need to change any framework or components code. A dynamic language is perfect for this.
I find that the mix of a statically typed language to build the system and a dynamically type language to configure it gives me flexibility, stability and productivity.
To answer the question of "What's with the love of dynamic languages?" For me it's the ability to completely re-wire a system at runtime in any way imaginable. I see the scripting language as "running the show", therefore the executing application may do anything you desire.
I don't have much experience with dynamic languages in general, but the one dynamic language I do know, JavaScript(aka ECMAScript), I absolutely love.
Well, wait, what's the discussion here? Dynamic compilation? Or dynamic typing? JavaScript covers both bases so I guess I'll talk about both:
Dynamic compilation:
To begin, dynamic languages are compiled, the compilation is simply put off until later. And Java and .NET really are compiled twice. Once to their respective intermediate languages, and again, dynamically, to machine code.
But when compilation is put off you can see results faster. That's one advantage. I do enjoy simply saving the file and seeing my program in action fairly quick.
Another advantage is that you can write and compile code at runtime. Whether this is possible in statically compiled code, I don't know. I imagine it must be, since whatever compiles JavaScript is ultimately machine code and statically compiled. But in a dynamic language this is a trivial thing to do. Code can write and run itself. (And I'm pretty sure .NET can do this, but the CIL that .NET compiles to is dynamically compiled on the fly anyways, and it's not so trivial in C#)
Dynamic typing:
I think dynamic typing is more expressive than static typing. Note that I'm using the term expressive informally to say that dynamic typing can say more with less. Here's some JavaScript code:
var Person = {};
Do you know what Person is now? It's a generic dictionary. I can do this:
Person["First_Name"] = "John"; Person["Last_Name"] = "Smith";
But it's also an object. I could refer to any of those "keys" like this:
Person.First_Name
And add any methods I deem necessary:
Person.changeFirstName = function(newName) {
this.First_Name = newName;
};
Sure, there might be problems if newName isn't a string. It won't be caught right away, if ever, but you can check yourself. It's a matter of trading expressive power and flexibility for safety. I don't mind adding code to check types, etc, myself, and I've yet to run into a type bug that gave me much grief (and I know that isn't saying much. It could be a matter of time :) ). I very much enjoy, however, that ability to adapt on the fly.
Nice blog post on the same topic: Python Makes Me Nervous
Method signatures are virtually useless in Python. In Java, static typing makes the method signature into a recipe: it's all the shit you need to make this method work. Not so in Python. Here, a method signature will only tell you one thing: how many arguments you need to make it work. Sometimes, it won't even do that, if you start fucking around with **kwargs.
Because it's fun fun fun. It's fun to not worry about memory allocation, for one. It's fun not waiting for compilation. etc etc etc
Weakly typed languages allow flexibility in how you manage your data.
I used VHDL last spring for several classes, and I like their method of representing bits/bytes, and how the compiler catches errors if you try to assign a 6-bit bus to a 9-bit bus. I tried to recreate it in C++, and I'm having a fair struggle to neatly get the typing to work smoothly with existing types. Steve Yegge does a very nice job of describing the issues involved with strong type systems, I think.
Regarding verbosity: I find Java and C# to be quite verbose in the large(let's not cherry-pick small algorithms to "prove" a point). And, yes, I've written in both. C++ struggles in the same area as well; VHDL succumbs here.
Parsimony appears to be a virtue of the dynamic languages in general(I present Perl and F# as examples).
참고 URL : https://stackoverflow.com/questions/42934/what-do-people-find-so-appealing-about-dynamic-languages
'your programing' 카테고리의 다른 글
| 두 목록을 사전으로 변환 (0) | 2020.09.27 |
|---|---|
| Visual Studio에서 솔루션 빌드, 솔루션 다시 빌드 및 솔루션 정리의 차이점은 무엇입니까? (0) | 2020.09.27 |
| socket.io를 사용하여 특정 클라이언트에 메시지를 보내는 방법 (0) | 2020.09.25 |
| CSS 여백 및 패딩 속기 속성의 순서에 대한 니모닉 (0) | 2020.09.25 |
| Java 변수 및 메소드 이름에 밑줄 사용 (0) | 2020.09.25 |