웹 사이트에 대한 동적 언어와 정적 형식의 언어

이 문장은 정적으로 입력 된 언어가 웹 사이트에 이상적이지 않다는 것을 나타냅니다.

웹 사이트 구축과는 대조적입니다. 웹 페이지를 렌더링 할 때 웹 페이지에서 상호 작용하는 구성 요소가 매우 많습니다. 여기에는 버튼이 있고 거기에는 작은 위젯이 있으며 웹 페이지에는 수십 개의 웹 페이지뿐만 아니라 웹 사이트에 수백 또는 수백 개의 웹 페이지가 모두 동적입니다. 표면적이 넓은 시스템에서는 정적으로 유형이 지정된 언어를 사용하는 것이 실제로 융통성이 없습니다. 버튼과 그 밖의 것을 대화식으로 밀고 싶을 때 Scala로 프로그래밍하고 웹 페이지를 렌더링하는 것이 고통 스럽습니다. 전체 시스템이 일관성이 있어야한다면 버튼 전체를 움직일 수 있도록 전체 시스템을 입력 해야하는 것처럼 실제로 유연하지 않을 수 있다고 생각합니다.

^{출처 : http://www.infoq.com/interviews/kallen-scala-twitter}

이 올바른지? 그 이유는 무엇?

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

또한 저자가 제시 한 예는 실제로 의미가 없습니다. 차라리 오리 타이핑 이외의 다른 방법으로 다형성을 달성 할 수 있다는 것을이 사람이 모르는 것처럼 보입니다.

동적 언어가 우수하다고 주장하는 사람들이 많이 있지만, 일반적으로 구조적 서브 타이핑, 대수 데이터 유형 및 1 차 함수를 지원하는 표현형 시스템에 대한 경험이 부족하기 때문입니다.

우선, 위 진술의 저자는 웹 사이트 개발에 대해 이야기하고 있음을 명심하십시오. 그래서 그는 프레젠테이션 개발 에 대해 걱정하고 있으며 스칼라가 좋은 선택이 아니라고 생각합니다 ...

나는 웹 개발에 대한 좋은 경험을 가지고 있습니다. 저는 디지털 에이전시에서 5 년 이상 독점적으로 8 년 동안 일했습니다.

그렇습니다. 제 경험 에 따르면 프레젠테이션 레이어 에서 정적으로 유형이 정해지고 컴파일 된 언어 가 큰 방해가 될 수 있습니다. 비즈니스 요구 사항보다 훨씬 자주 내용을 지속적으로 변경해야합니다. 그리고 이것은 보통 별개의 팀 ( "프론트 엔드"개발자)이 수행해야합니다. 그들은 일반적으로 HTML, JavaScript, 웹 표준, CSS에 대해 많이 알고 있지만 Java 및 C #과 같은 서버 측 언어에 대해서는별로 알지 못합니다. 또한 템플릿의 모든 종류의 변경 사항을 즉시 사용할 수 있다고 가정합니다 . 컴파일 및 유형 오류에 사용되지 않습니다. 정적으로 유형이 지정된 언어는 데이터 액세스 및 비즈니스 규칙과 같은 어렵고 복잡한 요구 사항에는 적합하지만 인터페이스 개발에는 적합하지 않습니다.

실제로 Velocity 와 같이 전문적이고 해석 된 템플릿 언어를 사용하면 얻을 수있는 주요 이점 중 하나입니다 . 프리젠 테이션 계층 개발자에게는 사용하기 쉽고 강력하며 유연성이 충분합니다. 그리고 서버 측 사람들은 다른 곳 어디에서나 정적이고 정적으로 유형이 지정된 언어를 자유롭게 사용할 수 있습니다 ...

그러나 나는 또한 Scala가 다소 다르다는 것에 동의합니다. 동시에 Java보다 훨씬 덜 장황하고 표현력이 뛰어나서 프레젠테이션 개발에 사용될 수 있다고 생각합니다 . 따라서 템플릿 언어로 성공적으로 사용될 수 있습니다. 또한 Play 와 같은 프레임 워크 (모든 변경 후에 웹 사이트를 자동으로 컴파일)와 결합 할 수 있다면 IMHO가 승자가 될 수 있습니다. 그럼에도 불구하고 Play조차도 Groovy와 같은 (동적) 템플릿 언어를 선택했는데 이는 좋은 징조가 아닙니다.

요약하자면, 스칼라의 문제는 컴파일 된 사실과 훨씬 관련이 있습니다. 사실 그 타입 추론 메커니즘은 당신이 만드는 거의 가 정적으로 입력 된 잊는다.

(내 영어에 대해 죄송합니다. 문제가 명확하지 않은 경우 알려 주시면 해결해 드리겠습니다.)

텍스트 (및 대부분의 답변)가 정적으로 유형이 지정된 언어와 지나치게 장황한 언어 가 혼합되어 있다고 생각합니다 . 물론, 교차로는 매우 큽니다 (특히 가장 주류 언어 만 고려할 때). 그러나 장황하고 정적으로 유형이 지정되지 않은 언어의 흥미로운 예가 있습니다 : Go, Haskell, Scala, Rust…

Bruce Eckel의 Strong Typing vs. Strong Testing 을 읽어 보시기 바랍니다 . 소프트웨어 품질은 모두 테스트로 귀결된다는 것이 주요 주장입니다. 다양한 방법으로 테스트 할 수 있습니다. 컴파일러는 컴파일 타임에 몇 가지 사항을 테스트합니다. int 변수에 문자열을 저장하려고하면 짖을 것입니다. 동적 언어에서는 런타임에 많은 테스트가 수행됩니다. 궁극적으로 테스트가 언제 수행되는지는 중요하지 않습니다. 그냥 일어나야합니다. 동적 언어로 컴파일하지 않으면 런타임시 테스트가 손실됩니다. 당신은 모든 것을 강력하게 테스트합니다.

이를 감안할 때 엄격한 유형 시스템과 동적 언어를 사용하는 컴파일 된 언어에 대한 선호는 그저 선호입니다. 권투 선수 대 팬티 또는 끈 팬티 대 프랑스 팬티의 종류. 옳고 그른 대답은 없습니다. 올바른 자세로 착용하면 굉장합니다.

나는 웹 플랫폼에서 고객을 다룰 때 유연성이 필수적이라고 생각하기 때문에 대부분의 경우에 동의합니다.

정적으로 유형이 지정된 언어는 유형이 다른 언어보다 강력하고 안전하지만 코드가 의도되지 않은 방식으로 작동하도록 코드를 적응시키기 시작하면 빠르고 필요할 때 솔루션은 복잡하고 엄격 해 보입니다.

따라서 기술 병합을 변경하면 정적으로 유형이 지정된 언어로 코어를 만들고 (코어는 많이 변경되지 않음) 사용자 상호 작용에 크게 사용하는 것이 좋습니다.

나는이 포스트의 저자가 스칼라 자신을 들여다 보지 않았다고 생각한다. Java와 C #에는 제한이 있으며 웹 개발에는 약간 융통성이 없다는 데 동의하지만 Scala는 정적 인 유형의 언어로, 일반적으로 듣고있을 때 생각하는 것과는 상당히 다릅니다. 스칼라는 원숭이 패치의 안전한 형식 버전으로도 오리 타이핑을 허용합니다 (암시 적 변환을 통해). 유형에 대해 생각해야하기 때문에 프로그래밍 라이브러리를 좀 더 복잡하게 만들지 만 Lift와 같은 라이브러리를 사용하는 경우 컴파일러가 사용하지 않는 명백한 버그에 대해 컴파일러가 알려주는 것을 제외하고는 동적 언어와 매우 흡사합니다. 권리. 나는 개인적으로 리프트 웹 프레임 워크가 루비 온 레일 또는 유사한 것을 숨길 필요가 없다고 생각합니다. 여기 또는 여기 에있는 코드 예제를 살펴보십시오스스로 결정하십시오. 나는 꽤 오랫동안 리프트로 개발했으며 유형 오류가있는 상황은 없었지만 "아, 이것이 역동적이라면 작동 할 것입니다 ... ... 동적이라면 그것은 나에게 말하지 않았을 것입니다. 런타임 중에 다운 될 때까지 버그가있었습니다.

개인적으로 나는 그들이 말하는 것이 웹 사이트뿐만 아니라 모든 시스템에 해당한다고 생각합니다. 하드웨어와 대화 할 때 정적 타이핑이 필요합니다. 다른 모든 타이핑은 실제로 수행하는 작업과 관계없이 동일한 단점과 이점이 있으며 각 프로젝트의 취향과 특정 문제에 따라 가장 좋은 것이 무엇인지에 따라 달라집니다.

실용 빠른 답변 : 웹 크기의 크기와 복잡성에 따라 다릅니다. 소규모 웹 사이트, 동적 생성 lang., Complex Large 웹 사이트, 정적 프로그램 언어.

확장 된 지루한 답변 : 많은 개발자들은 웹 사이트가 동적 프로그램으로 이루어져야한다고 주장합니다. Langr. 그러나 실제로 웹 개발 도구는 정적 유형 언어를 사용하거나 에뮬레이트하는 경향이 있습니다.

PHP로 여러 번 작업했으며 조만간 주어진 데이터의 유형을 확인하는 많은 코드를 추가해야했습니다. 정적 유형의 progr에 내재되어 있습니다. 언어.

입력 된 Lagn. 또한 많은 유형 검증이 필요한 IDE 사용에 도움이됩니다.

(인접 이웃 프로듀서 및 컴파일러 디자이너가 가져옴 ;-))

동의합니다. 대부분의 웹 프런트 엔드 C # 코드를 보면 문자열에서 캐스팅하고 데이터를 문자열로 직렬화하는 방법이 많이 있습니다. 기본적으로 프로토콜 인 HTTP는 동적 언어에 적합합니다.