문제

내가 언어 디자인에 관한 토론에서, 많은 사람들이 "하나의 진정한 언어"가없고 결코 없을 것이라는 주장을하는 것처럼 보입니다. 이 사람들에 따르면 대안은 여러 언어에 익숙하고 작업에 적합한 도구를 선택하는 것입니다. 이것은 매우 좁고 잘 정의 된 인터페이스를 통해 나머지 프로젝트와 만 상호 작용 해야하는 전체 프로젝트 또는 대규모 하위 프로젝트 수준에서 완벽하게 의미가 있습니다.

반면에, 많은 다른 언어를 사용하는 것은 우아하게 작은 하위 문제를 많이 해결하려고 할 때해야 할 매우 어색한 일처럼 보입니다. 다시 말해, IMHO, 모든 것에 적당한 범용 언어는 여전히 중요합니다. 사소한 예로, 다음을 수행해야한다고 가정 해 봅시다.

  1. 파일에서 임의의 형식으로 많은 데이터를 읽으십시오. 오류 등을 확인하십시오 (Perl과 같은 것이 가장 좋습니다).
  2. 이 데이터를 매트릭스에로드하고, 많은 하드 코어 매트릭스 OP를 수행하십시오 (MATLAB과 같은 것이 가장 좋습니다).
  3. 빠르고 공간 효율적이어야하는 사용자 정의 계산 집약적 루틴을 실행하십시오 (C 또는 C ++에서 가장 잘 수행).

이것은 계산 집약적 인 사용자 정의 매트릭스 처리 루틴을 작성하는 것 외에도 상당히 간단한 프로젝트이지만, 어떤 언어를 사용하는지에 대한 유일한 좋은 답변은 모든 것에 대해 괜찮은 일반적인 목적으로 보입니다.

내가 여기서 무엇을 놓치고 있습니까? 여러 언어를 어떻게 효과적으로 사용하여 각 강점을 활용합니까?

도움이 되었습니까?

해결책

나는 상당히 다양한 언어 혼합을 포함하는 많은 프로젝트에서 일했습니다. .NET 프로젝트가 아니라면 일반적으로 다른 계층 또는 다른 프로세스에서 이러한 다른 언어를 사용합니다. 아마도 WebApp이 PHP에 있고 Application Server가 Java에있을 수 있습니다. 따라서 메소드 레벨에서 실제로 "혼합 및 일치"하지 않습니다.

.NET 및 일부 Java VM 언어의 경우 규칙이 훨씬 더 자유롭게 혼합 될 수 있으므로 규칙이 약간 변경됩니다. 그러나 이러한 언어의 특징은 대부분 공통적 인 클래스 라이브러리에 의해 정의됩니다. 따라서 .NET에서 언어를 전환하려는 동기는 일반적으로 개발자가 알고있는 언어와 같은 다른 요인에 의해 주도됩니다. F#는 실제로 해당 언어에 특정한 몇 가지 언어 기능을 제공하므로 .NET 내에서 약간의 예외 인 것 같습니다. Java VM 언어 중 일부는 표준 Java 라이브러에 메소드를 추가하여 Java에서 사용할 수없는 기능을 추가합니다.

당신은 실제로 모든 언어가 좋은 IDE 지원을받는 한 여러 언어로 작업하는 데 실제로 익숙해집니다. 그없이 나는 정말로 내가 길을 잃을 것이라고 생각한다.

다른 팁

Lua와 같은 내장 언어는 이것을 쉽게 만듭니다. LUA는 루비 또는 파이썬 라인을 따라 훌륭한 역동적 인 언어이며 고품질 코드를 신속하게 개발할 수 있습니다. 또한 C와의 긴밀한 통합이있어 C/C ++ 라이브러리를 활용하고 C 또는 C ++로 작성하여 성능 중요 섹션을 최적화 할 수 있습니다.

과학적 컴퓨팅에서는 예를 들어 MATLAB에서 일부 데이터 처리를 수행하고 Perl을 사용하여 출력을 재구성 한 다음 MATLAB, C 등으로 작성된 다른 앱으로 전달하는 스크립트를 갖는 것은 드문 일이 아닙니다. 그러나 이것은 처음부터 무언가를 개발할 때와 다른 사람들이 작성한 앱을 통합 할 때 더 흔한 경향이 있습니다.

작업의 가장 어려운 부분을 고려하십시오. 파일을 가장 복잡한 부분입니까? 파일을 읽는 데 좋은 언어를 작성한 다음 조작하는 것이 가장 적절한 선택 일 수 있습니다.

수학 변환이 가장 어려운 부분입니까? 당신은 그것을 빨고 matlab을 사용하여 스크립트 나 다른 가정에서 자란 도구로 먹이를주고 싶을 수도 있습니다.

성능이 가장 중요한 부분입니까? 변환 및 구문 분석에 비해 얼마나 많은 계산이 수행됩니까? 수행 된 작업의 90%가 계산 중이고 다른 부분이 일시적이면 C/C ++ 솔루션을 고려하십시오.

간단한 솔루션에서 여러 언어 강점을 재생하는 데 본질적으로 잘못된 것은 없습니다. 특히 스크립트와 함께 접착하지 않는 경우. 그러나 더 많은 언어와 모듈이 통합 될수록 종속성을 증가시키고 종속성이 많을수록 앱을 배포하고 유지하기가 점점 어려워집니다. 그곳에서 실제 트레이드 오프가있는 곳입니다. 앱을 실행하는 데 필요한 기술, 라이브러리 및 소프트웨어 비트가 적을수록 더 간단 해집니다. 앱이 더 간단할수록 유지 관리 가능하고 분배 가능하며 디지털화 가능하며 사용 가능합니다.

여러 기술을 통합하는 추가 오버 헤드를 신경 쓰지 않거나 그 간접비가 동일하거나 더 많은 개발 시간을 절약 할 수 있다면 바로 앞으로 나아갈 수 있습니다.

괜찮다고 생각합니다. 각 레이어가 동일한 방식 (SOAP/XML/COM 등)에 액세스하는 N-Tier 설정으로 설정하면 결국에는 보이지 않는 것으로 나타났습니다.

예를 들어, 나는 프론트 엔드를위한 하나의 언어를 쉽고 빠르며 유연하며 COM, Corba, XML, .NET,와 같은 다양한 인터페이스에 대한 많은, 수많은 유형의 통화를 만들 수 있습니다. 맞춤형 DLL 라이브러리, FTP 및 사용자 정의 이벤트 게이트웨이. 이렇게하면 다른 lanugage와 쉽게 호출하거나 인터페이스 할 수 있습니다.

이것에 대한 나의 선택 도구는 ASP/PHP/Java와 약간의 루비로 작업함으로써 냉담입니다. 그것은 모든 것을 한 곳에 가지고있는 것처럼 보이며 매우 간단합니다. 특정 사례의 경우 ColdFusion을 사용하면 웹 코드에서 호출 할 수있는 자신의 라이브러리 태그를 컴파일 할 수 있습니다. 태그 내부에서 원하는 모든 C 코드를 넣고 원하는대로 할 수 있습니다.

무료 및 오픈 소스 버전의 ColdFusion이 사용 가능하며 Java 및 .NET가 하나의 코드 기반에서 순진하게 전화를 걸기에 환상적입니다. 확인하십시오. 이런 종류의 기업 솔루션에 적합한 것이 가장 적합하다고 생각합니다.

나는 당신의 상황에 따라 PHP가 이것에도 꽤 좋을 수 있다는 것을 알고 있으며, ASP.net은 너무 뒤지지 않을 것이라고 확신합니다.

여러 언어로 된 저의 작업에는 C#과 C ++/CLI의 간단한 혼합이 포함되었습니다 (들어 본 적이없는 경우 .NET과 C ++와 같습니다). .NET과 Visual Studio가 많은 다른 언어를 결합 할 수있는 방식은 두 언어를 결합 할 때 일반적으로 기대할 수있는 오버 헤드가 없다는 것을 의미한다고 말할 가치가 있다고 생각합니다. Visual Studio는 모든 것을 유지합니다. 함께. F#, Ironpython, Ironruby, JScript.net과 같은 다양한 언어의 많은 .NET 클론이 많다는 점을 감안할 때 Visual Studio는 다양한 언어를 결합 할 수있는 좋은 방법입니다.

관심있는 기술과 같은 기술적 수준까지, Visual Studio에서 수행하는 방식은 각 별도의 언어마다 하나의 프로젝트가 있어야하며 각 프로젝트가 어셈블리로 컴파일되는 것입니다. 사용할 다른 프로젝트. 모든 것을 운전하고 다른 도서관을 호출하는 하나의 주요 프로젝트가 있습니다. 다른 프로젝트가 다른 각 언어의 요구 사항은 방법 수준에서 언어를 변경하지 않지만 여러 프로젝트로 논리적으로 분리 할 수있는 충분한 응용 프로그램을 수행하는 경우 실제로 매우 유용 할 수 있습니다. 특히, 분리와 추상화는 전반적으로 일을 더 쉽게 만들 수 있습니다.

당신은 선택이 a) a) 한 언어로 모든 것을 쓰고 효율성을 잃거나 b) 작업의 각 섹션에 가장 적합한 언어를 사용하기 위해 다양한 실행 파이브를 함께 모을 것이라고 말합니다.

대부분의 작업 프로그래머는 옵션 C를 선택합니다. C : IT 부서에서 생산에서 지원하는 언어로 최선을 다합니다. 일반적으로 프로그래머는 JVM 또는 CLR과 같은 특정 프레임 워크 내에서 제한된 언어 선택을 가지고 있으므로 Toolbox Utopia 나 단일 언어 빈민가가 아닙니다.

램프와 레일조차도 html, javascript, ruby, cless의 경우 다른 수준의 다른 언어를 지원합니다. 소프트웨어 서비스를 작성하는 경우 (요즘 흥미로운 작품이 일어나고있는 곳) 하나의 언어로는 거의 글을 쓰지 않습니다. 그러나 당신의 선택도 무한하지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top