하나의 제품 또는 소프트웨어를 개발할 때 여러 프로그래밍 언어가 사용되는 이유는 무엇입니까?

저는 컴퓨터 공학 석사 학위를 시작하려는 최근 졸업생입니다. 나는 정말로 흥미를 유발하는 여러 가지 오픈 소스 프로젝트를 접하고 그 프로젝트에 기여하도록 장려했습니다 (CloudStack, OpenStack, moby 및 Kubernetes). 내가 찾은 것 중 하나는 Java + Python + Go 또는 Python + C ++ + Ruby와 같은 여러 프로그래밍 언어를 사용한다는 것입니다. 나는 이미 다른 질문을 보았습니다.이 질문은 여러 프로그래밍 언어가 서로 통신하는 방법을 다루고 있습니다. 두 개의 다른 언어를 가진 두 개의 다른 프로그래밍이 상호 작용하는 방법은 무엇입니까?

기업이 여러 프로그래밍 언어를 사용하도록 요구하는 요구 사항을 이해하고 싶습니다. 소프트웨어 설계자 또는 프로젝트 책임자는 "요구 사항 1에 언어 X를 사용하고 작업 2에 언어 Y를 사용하고 싶습니다"라고 말하는 요구 사항 또는 유형은 무엇입니까? 여러 제품 언어가 동일한 제품이나 소프트웨어에 사용되는 이유를 이해할 수없는 것 같습니다.

이 답변 에는 다른 언어가 프로젝트에 뚜렷한 이점을 제공 할 수있는 이유에 대한 훌륭한 설명과 링크가 있습니다. 그러나 프로젝트가 여러 언어를 사용하는 이유는 언어 적합성에 그치지 않습니다.

프로젝트는 6 가지 주요 이유로 여러 언어를 사용합니다.

1. 다른 언어로 작성된 코드를 재사용하면 비용이 절감됩니다.
2. 레거시 코드를 포함하고 수용 할 필요성
3. 특정 언어에 대한 코더의 가용성;
4. 특수 요구를위한 특수 언어의 필요성;
5. 레거시 언어 편향; 과
6. 빈약 한 프로젝트 관리 (계획되지 않은 다국어 사용).

이유 1 ~ 4는 직접 문제를 해결하면 고품질의 제품과보다 쉬운 장기 지원으로 프로젝트를보다 빠르고 효율적으로 결론을 내릴 수 있다는 긍정적 인 이유입니다. 이유 5와 6은 부정적이며, 필요한 변화에 대한 내성의 증상, 계획이 잘못되었거나, 비효율적 인 관리 또는 이러한 모든 요소의 일부 조합입니다. 불행히도 이러한 부정적인 요소는 "우연한"다국어 사용의 일반적인 원인입니다.

재사용의 비용 이점 인 이유 1 은 오픈 소스 소프트웨어의 역할이 커지고 웹에서 올바른 코드 구성 요소를 찾을 수있는 기능이 향상되어 프로젝트에서 여러 언어를 사용할 수있는 강력한 이유가되었습니다. 지난 수십 년간의 "내부적으로 코드를 작성하자"라는 철학은 경제 현실에 직면하여 계속 사라지고 있으며, 새로운 프로젝트에있어 가장 비용 효율적인 방법은 아닙니다. 결과적으로 프로젝트 내에서 단일 언어 사용을 엄격하게 시행 할 수있는 기회가 줄어 듭니다.

특히 잘 관리되는 오픈 소스 구성 요소를 재사용하는 프로젝트의 경우, 재사용 된 구성 요소가 잘 설계된 인터페이스 뒤에 숨겨져 있고 비용이 많이 들지 않는 외부 그룹에 의해 독립적으로 유지 관리되므로 여러 언어를 사용하면 전체적으로 큰 비용 이점을 얻을 수 있습니다. 최상의 시나리오에서 이러한 종류의 재사용을 통해 언어를 혼합하는 것은 운영 체제 구성 요소를 사용하는 것보다 비용이 많이 들지 않습니다. 필자는 브라우저에서 Microsoft가 오픈 소스 소프트웨어를 대규모로 채택한 것보다이 접근 방식의 가치에 대한 더 나은 예를 알고 있지 않습니다.

레거시 코드를 수용해야하는 이유 2 는 대규모 프로젝트의 위험에 따라 무시됩니다. 그러나 레거시 코드가 많은 문제를 일으킬 수 있지만, 새로운 언어로 새 코드로 쉽게 교체 할 수 있다고 가정하면 순진하게 위험 할 수 있습니다. 레거시 코드, 심지어 레거시 코드조차도 레거시 제품을 사용하는 커뮤니티에서 예상되는 기능의 암시 적 "계약"에 해당하는 양이 종종 포함됩니다. 이 커뮤니티는 종종 회사의 주요 수입원이거나 정부 소프트웨어 지원의 주요 목표입니다. 묵시적 계약을 버리는 것만으로도 운전중인 고객을 인식 할 수 있으며 다른 옵션을 쉽게 사용할 수있는 경우 밤새 회사를 파산 할 수 있습니다.

동시에, 오래된 언어로 된 오래된 코드를 교체 하지 않는 것은 도매하는 것만 큼 위험 할 수 있습니다. 최악의 예는 미국 재향 군인 관리국인데, 컴퓨터 과학자가 아닌 의사가 설계 한 MUMPS (농담 없음)라는 언어로 코딩 된 많은 필수 시스템이 있습니다. 아무도 MUMPS를 배우기를 원하지 않으며 그것을 알고있는 사람들은 말 그대로 죽어 가고 있습니다. 따라서 프로그래머는보다 일반적이고 강력하며 더 잘 유지 관리되는 다른 언어를 사용하려는 경우에도 MUMPS를 수용해야합니다.

이 유형의 다국어 사용에는 신중한 계획이 필요합니다. 이러한 계획은 수십 년 동안 고객 지식을 잃어 버리는 것과 다른 한편으로는 소프트웨어를 지원할 수있는 능력을 잃는 것 사이의 경계를 탐색해야합니다. 이전 코드를 잘 정의 된 인터페이스로 격리하고 동작이 잘 문서화 된 후 이전 코드를 대체 할 수있는보다 강력한 새 코드를 가능하게하는 기술이 도움이 될 수 있습니다. 그러나이 레거시 시나리오는 결코 쉬운 일이 아니며 광범위한 회사에서 많은 회사와 조직이 사망 한 원인이되었습니다.

다양한 언어의 코더를 사용할 수있는 이유 3 은 프로젝트가 위험에 처한 것을 무시하는 실용적인 요소입니다. 그러나 많은 프로젝트 주최자는 특정 언어가 목표에 가장 적합하다고 생각할 수 있습니다 (올바르거나 잘못). 해당 언어가 사용 가능한 언어 전문 지식 풀과 충돌하는 경우 제품의 일정과 품질이 학습으로 인해 어려움을 겪을 수 있습니다. 새로운 언어를 배우려고 노력하는 프로그래머의 곡선.

보다 합리적인 접근 방식은 기능 영역을 기반으로 프로젝트의 언어 요구를 분석하는 것입니다. 예를 들어, 프로젝트를주의 깊게 살펴보면 일반적으로 덜 사용되는 언어의 코딩 전문 지식을 필요로하는 일부 독점 알고리즘을 구현하기 위해 고 가치 코드의 작은 "정점"만 있음을 알 수 있습니다. 대규모 프로젝트의 다른 부분은 종종 더 일반적인 언어 또는 잘 관리되는 오픈 소스 제품으로 쉽게 수용 할 수 있습니다. 따라서 언어 요구에 따라 프로젝트를 분석하면 특수 언어로 특수 전문 지식을 고용하거나 임대하는 데 훨씬 더 현실적이고 비용 효율적인 방법을 제공 할 수 있으며 단일 프로젝트 내에서 언어 간 인터페이스를 선명하게 할 수 있습니다.

다양한 요구에 다른 언어를 사용하는 이유 4 는 그러한 종류의 프로젝트 요구에 대한 분석을 수행하는 즉시 즉각적으로 이어집니다. 단일 프로젝트 내에서 지원할 언어를 너무 많이 선택하면 지원 및 구성 요소 간 인터페이스가 복잡해 지므로 폭발적으로 복잡해질 수 있습니다. 비용 대비 가장 안전한 경로는 항상 재사용이 가능한 최대 기회를 찾는 것입니다. 특히 커스터마이즈 이상으로 프로젝트 요구를 충족시킬 수있는 우수한 패키지가있는 경우 더욱 그렇습니다. 다음으로, 식별 된 대부분의 요구를 해결할 수있는 소수의 언어에 대해 어떤 종류의 결정을 내려야합니다. 재사용 집약적 인 개발에서 이것은 종종 일종의 접착제 코드 일 것입니다.

프로젝트의 일부 멤버는 다른 멤버와 유사하기 때문에 매우 유사한 기능을 가진 여러 언어를 선택하는 것은 일반적으로 좋지 않습니다 . 그러나 특수 언어 기술을 활용할 수있는 잘 정의되고 잘 정의 된 기능 하위 집합이있는 경우 새로운 코드 개발에 여러 언어를 사용하는 것이 좋습니다.

사용 된 언어의 필요한 변경에 대한 저항 인 이유 5 는 심각한 프로젝트 중단 및 내부 분쟁의 원인이 될 수 있습니다. 사용자 Daveo이 답변에 대한 의견에서 지적했듯이 일부 프로젝트 직원에게는 변경이 매우 어려울 수 있습니다. 동시에, 변화에 대한 저항은 결코 간단한 문제가 아니며, 그것이 많은 투쟁을 일으킬 수있는 이유입니다. 레거시 언어가 충분히 강력 할 경우 레거시 언어 기술을 사용하면 프로젝트 생산성이 크게 향상 될 수 있으며, 원활하게 운영되고 품질을 존중하는 팀에서 우수한 품질의 제품으로 이어질 수 있습니다. 그러나 레거시 언어 기술은 고급 기능, 구성 요소 가용성, 오픈 소스 옵션 및 지능형 도구 키트 지원 측면에서 더 많은 최신 언어를 더 이상 최신 언어로 완성 할 수 없다는 사실과 균형을 이루어야합니다.

그 당시와 현재, 더 약하고, 읽기 어렵거나, 덜 생산적인 레거시 언어를 계속 사용한다는 가장 일반적인 (그리고 아이러니하게도, 가장 자주 올바른) 단일 주장은 오래된 언어가 더 효율적인 코드를 생성 할 수 있다는 것이 었습니다. 이것은 어셈블리 언어 사용자가 종종 FORTRAN과 LISP에서 프로그래밍의 출현을 다시 불러 일으켰을 때 1950 년대로 거슬러 올라가는 오래된 논쟁입니다. 현재까지도 코드 효율성 인수가 유효 할 수있는 예는 운영 체제 커널과 같은 처리 집약적 코드에서 볼 수 있습니다. 여기서 운영 체제 커널은 C가 C ++보다 선호하는 언어로 남아 있습니다 (단순한 효율성을 넘어서는 이유가 있습니다).

그러나 전 세계적으로 네트워크화되고 강력하게 기계적으로 지원되는 새로운 밀레니엄 프로젝트 환경에서 프로젝트 언어 선택의 주요 논거 인 코드 효율성은 더욱 약화되었습니다. 인공 지능 응용 프로그램의 대량 마케팅을 가능하게 한 컴퓨팅 및 네트워킹 하드웨어의 폭발은 인간 프로그래밍 비용이 놀라 울 정도로 저렴한 하드웨어 및 클라우드웨어에서 비효율적 인 코드 실행의 비용을 쉽게 능가 할 수 있음을 의미합니다. 최신 버전의 구성 요소 라이브러리, 오픈 소스 옵션 및 고급 지능형 툴 키트에 대한 가용성이 높아지면 효율성을 이유로 언어를 유지하는 경우가 매우 좁아집니다. 적용되는 경우에도

프로젝트가 레거시 언어를 유지하는 더 매력적인 이유는 프로젝트가 직원 변경 옵션이 거의 없거나 전혀없는 경우에 발생합니다. 예를 들어 주요 레거시 제품군이 기존 직원 만 능숙한 언어로 완전히 코딩 된 경우에 발생할 수 있습니다. 이러한 경우 프로젝트는 구식 언어로 프로그래밍하려는 노력을 계속하거나 기존 직원에게 새로운 언어 사용 방법을 교육시켜야합니다.

새로운 언어로 레거시 언어 직원을 훈련시키는 것은 그 자체로 위험 할 수 있습니다. 나는 C에서 C ++로 방금 훈련되고 전환 된 프로젝트 멤버가 객체 지향 메소드의 이점을 이해하지 못했다고 진정으로 나에게 불평 한 사례를 회상합니다. 내가 그의 코드를 볼 때, 그는 이전의 103 C 함수를 단일 C ++ 객체 클래스에 대한 103 메소드로 변환했으며 ... 어떻게 도움이되는지 보지 못했습니다.

더 깊은 메시지는 사람들이 수십 년 또는 수십 년 동안 단일 언어 및 언어 스타일로 프로그래밍했을 때 새로운 훈련 방식으로 "생각"하기가 어려워 질 수 있다는 것입니다. 어떤 경우에는 현재의 트렌드와 방법에 더 잘 적응하는 젊은 디자이너와 프로그래머를 불러오는 것 외에 다른 옵션이 없을 수도 있습니다.

프로젝트 관리가 열악한 이유 6 은 그 자체를 말합니다. 프로젝트에서 언어 선택 및 사용은 항상 명시 적으로 고려되고 평가되어야하며 우연히 발생해서는 안됩니다. 최소한 언어 선택은 프로젝트의 장기적인 운명과 지원 비용에 큰 차이를 만들 수 있으므로 항상 고려하고 계획해야합니다. MUMPS가되지 마십시오!

동일한 제품이나 소프트웨어에 여러 프로그래밍 언어가 사용되는 이유를 이해할 수없는 것 같습니다.

매우 간단합니다. 모든 요구와 목표에 적합한 단일 프로그래밍 언어가 없습니다.

Michael L. Scott의 책 Programming Language Pragmatics 읽기

일부 프로그래밍 언어 표현력 및 선호 declarativity (스크립트 언어의 많은뿐만 아니라 같은 높은 수준의 프로그래밍 언어 AGDA , 프롤로그 , 리스프 , 하스켈, OCaml로, ...)를. 개발 비용이 중요한 경우 (인간 시간 및 개발자 비용) 런타임 성능이 최적이 아닌 경우에도 개발 비용을 사용하는 것이 적합합니다.

다른 프로그래밍 언어는 런타임 성능을 선호합니다 (일반적으로 C ++, Rust, Go, C, 어셈블러, OpenCL과 같은 특수 언어와 같은 컴파일 된 구현을 가진 많은 저수준 언어). 종종 그들의 명세는 정의되지 않은 행동을 허용한다 . 코드 성능이 중요한 경우에는 이러한 언어를 사용하는 것이 좋습니다.

일부 외부 라이브러리 는 특정 언어 및 ABI 및 호출 규칙 을 염두에두고 작성되었습니다. 다른 언어를 사용해야하고 외부 코드 인터페이스 규칙을 따라야 할 수도 있습니다 .

실제로, 표현력이 높고 (숙련 된 충분한 개발자 팀을 가정하여 개발자의 생산성을 향상시키는) 프로그래밍 언어가 런타임에 매우 우수한 프로그래밍 언어를 가질 가능성은 없습니다. 실제로는 표현 성과 성능간에 균형이 있습니다.

참고 : 그러나, 몇 가지가 있었다 느린 프로그래밍 언어에서 진행 : 녹가 C 또는 심지어 C보다 더 표현입니다 ++ 있지만 구현이 거의 확대됨에, 그리고 아마 똑같이 빠른 실행 파일을 생성하기 위해이 향상됩니다. 따라서 직업 생활 동안 새로운 프로그래밍 언어를 배워야합니다. 그러나은 총알 이 없습니다

오늘날 개발 비용이 점점 더 중요하다는 점에 주목하십시오 (1970 년대에는 비용이 많이 들거나 일부 임베디드 응용 프로그램의 컴퓨터가 대량의 제품을 사용하는 컴퓨터의 경우). 경험적으로 볼 때 숙련 된 개발자는 매년 약 25,000 줄의 (디버그 및 문서화 된) 소스 코드를 작성할 수 있으며 사용되는 프로그래밍 언어에 크게 의존하지 않습니다.

일반적인 접근 방식은 대규모 응용 프로그램에 일부 스크립팅 언어 (또는 일부 도메인 특정 언어 )를 포함시키는 것입니다. 이 디자인 아이디어 (도메인 특정 언어와 관련됨)는 수십 년 동안 사용되어 왔습니다 . 1980 년대 이후 스크립팅에 Elisp를 사용 하는 Emacs 소스 코드 편집기 가 좋은 예입니다 . 그런 다음 Guile , Lua , Python 과 같이 쉽게 임베드 가능한 인터프리터를 사용합니다, ...) 더 큰 응용 프로그램 내에서. 큰 응용 프로그램에 인터프리터를 포함시키는 결정은 매우 일찍 이루어져야하며 아키텍처에 큰 영향을 미칩니다. 그런 다음 두 가지 언어를 사용합니다. C 또는 C ++와 같은 저수준 언어; 고급 스크립트의 경우 다른 DSL 또는 스크립팅 언어

또한 특정 소프트웨어는 일종의 프로세스 간 통신 기술을 사용하는 여러 협력 프로세스 에서 대부분의 최신 운영 체제 (Linux, Windows, Android, MacOSX, Hurd 등) 내에서 실행될 수 있습니다 . 분산 컴퓨팅 기술 (예 : 클라우드 컴퓨팅 , HPC, 클라이언트 서버, 웹 응용 프로그램 등 )을 사용하여 여러 컴퓨터 (또는 여러 컴퓨터)에서 실행될 수도 있습니다 . 두 경우 모두 여러 프로그래밍 언어를 사용하기 쉽습니다 (예 : 하나의 프로세스 또는 컴퓨터에서 실행되는 각 프로그램을 자체 프로그래밍 언어로 코딩). 자세한 내용은 운영 체제 : 쉬운 세 가지를 읽으십시오 . 또한 외부 기능 인터페이스(예 : JNI ), ABI , 호출 규칙 등은 동일한 프로그램 (또는 실행 파일 ) 에서 여러 언어를 혼합하는 것을 용이하게 합니다. SWIG 와 같은 코드 생성기 가 도움이됩니다.

어떤 경우에는, 당신이 해야 할 몇 가지 프로그래밍 언어를 혼합 : 웹 응용 프로그램은 자바 스크립트 또는 Webassembly이 부분은 브라우저에서 실행하는 (유일한 언어는 대부분의 웹 브라우저 내에서 실행)가 필요합니다 (프레임 워크가 발생 , 예를 들어, 이러한 ocsigen ). 커널 코드는 C 또는 C ++에서 필요한 것을 표현할 수없고, RDBMS 쿼리는 SQL을 사용해야하고, GPGPU 는 OpenCL로 코딩 된 컴퓨터 커널 이 필요하기 때문에 어셈블러로 부분적으로 작성해야하는 것들 (예 : 스케줄러 또는 인터럽트의 낮은 수준의 처리)이 필요 합니다. 또는 CUDA C 또는 C ++ 호스트 코드에서 관리 등은 .... 일부 언어는 (예를 들면 혼합물을 촉진하기 위해 예를 들어 설계 문 , C에서을asm내 늦은 GCC MELT 등의 코드 청크 등 ...).

경우에 따라 메타 프로그래밍 기술 을 사용 합니다. 대규모 소프트웨어 프로젝트의 일부 부분에는 일부 특수 형식화에서 다른 도구 (아마도 프로젝트 특정 도구)에서 생성 한 코드 (예 : C 또는 C ++)가 있습니다. 파서 생성기 (부적절하게 컴파일러- bison 또는 ANTLR 과 같은 컴파일러 뿐만 아니라 SWIG 또는 RPCGEN도 떠 오릅니다. 그리고 GCC 에는 그 안에 12 개 이상의 특수 C ++ 코드 생성기 (GCC 내부의 모든 내부 DSL에 하나씩)가 있습니다. 이 예제 도 참조하십시오 . 알 수 metabugs은 찾기 어렵다. 부트 스트랩 컴파일러 및 호모 닉 및 리플렉션 에 대해서도 읽어보십시오.( Lisp 를 배우고 , SBCL을 가지고 놀며 , SICP 를 읽고, GCCJIT 와 같은 JIT 컴파일 라이브러리 를 살펴보십시오 ; 일부 큰 프로그램에서는 런타임에 코드를 생성 할 수 있습니다; Greenspun의 10 번째 규칙을 알고 있어야합니다 ). FOSDEM2018 의 Circuit Less Traveled 강의도 참조하십시오.

때로는 특수 주석 언어 (일부 DSL로 표시 될 수 있음)를 사용하여 코드의 공식 주석을 제공하려고합니다 (예 : 프로 버, 정적 분석기, 컴파일러 등). Frama-C 로 ACSL을 조사 하여 C 프로그램 (안전에 중요한 프로그램) 또는 HPC에 대한 OpenMP pragma에 주석을 답니다 . 주의 사항 : 이러한 주석을 작성하려면 많은 기술과 개발 시간이 필요할 수 있습니다.

BTW는 컴파일러와 인터프리터에 대한 일부 기술이 모든 개발자에게 유용하다는 것을 시사합니다 (컴파일러 내부에서 작업하지 않아도). 따라서 컴파일러 작업을하지 않더라도 Dragon Book을 읽으십시오 . 자신 만의 통역사를 코딩하거나 DSL을 디자인하는 경우 Lisp In Small Pieces도 참조하십시오 .

참조 이 & 그 & 그 & 그 질문에 관련된 내 대답.

영감과 깨달음을 위해 여러 가지 큰 자유 소프트웨어 프로젝트 ( github 또는 Linux 배포판 ) 의 소스 코드도 연구 하십시오 .

또한 일부 프로그래밍 언어는 기존 언어에 주석 (프 래그 마 또는 주석 )을 추가하여 발전했습니다 . 예를 들어, 생각 ACSL (하여 교정을 가능하게하는 C 프로그램에 주석을 주석 - 확장 FRAMA-C 또는의) 오픈 CL 또는 (A C 방언이 GPGPUs 프로그램) 의 OpenMP 또는 OpenACC #pragma의 또는 CL의 유형 약어 .

추신 : 프로그래밍 언어를 혼합 해야하는 사회적 또는 조직적 또는 역사적 이유도 있습니다. 나는 여기서 무시하고 있지만 실제로 그러한 이유가 지배적이라는 것을 알고 있습니다. 신화적인 남자의 달 읽기

많은 프로젝트가 여러 프로그래밍 언어로 구축 되지 않았습니다 . 그러나 소프트웨어를 지원하기 위해 다른 언어로 된 스크립트를 사용하는 것이 일반적입니다.

• 별도의 프로그램 인 관리 도구는 때때로 다른 언어로 작성됩니다.
• 라이브러리와 API는 종종 여러 언어에 대한 바인딩을 제공하므로 개발자는 원하는 언어를 사용할 수 있습니다.
• 빌드 스크립트 및 관련 개발 스크립트는 종종 특수 언어를 사용합니다.
• 어플리케이션의 엔드 투 엔드 테스트는 동일한 언어를 사용할 필요가 없습니다.

일부 프로젝트는 응용 프로그램 내에서 여러 언어를 사용합니다 (예 : 스크립팅 언어로 플러그인을 통합 할 수있는 하위 언어의 핵심). 일부 에코 시스템 (예 : JVM 또는 .NET)에서는 동일한 언어 런타임의 여러 언어가 상호 운용성이 우수하므로 사용되는 정확한 언어가 그다지 중요하지 않습니다. 예를 들어, 기존 Java 라이브러리를 사용하고 스크립트 기능을 Groovy와 통합하는 프로젝트를 Scala로 작성할 수 있습니다.

프로젝트가 여러 도구로 구성된 경우 다른 언어로 개발할 수도 있습니다. 일관성, 특히 오픈 소스 프로젝트의 경우 일관성이 좋을 수 있지만 사용 가능한 개발 노력은 병목 현상이 될 수 있습니다. 누군가 유용한 도구를 기꺼이 개발하려고하지만 주 언어에 익숙하지 않은 경우 해당 도구가 일관성보다 더 가치가있을 수 있습니다.

여기에는 두 가지 형식이 있으며 두 조직 사이에있는 많은 조직이 있습니다.

나쁜 형태 -조직은 엉망이며 아무도 노력에 대한 단일 기술적 비전이 있는지 확인하지 않습니다. 개발자는 가장 편한 언어를 사용하거나 최근에 새로운 프레임 워크 또는 언어를 실험하고 순진한 낙관주의로 인해 간단히 사용하기로 결정했습니다.

좋은 형태 -조직은 폴리 글 로트 프로그래밍에 적합하도록하는 아주 훌륭하고 깨끗한 아키텍처를 가지고 있습니다. 잘 정의 된 경계 컨텍스트를 사용하여 응용 프로그램을 독립 구성 요소로 분리하고이 조합을 통해 특정 구성 요소를 작성할 수있는 프로그래밍 언어를 선택할 수 있습니다.

현실 -일반적으로 후자보다 전자입니다. 나는 몇몇 회사가 비즈니스 도메인과 웹 서버에 대해 하나의 언어를 선택하고 데이터베이스 관리에 대해 세 번째 언어를 선택하는 것을 보았습니다. 기술적으로는 좋지만 곧 기술 이해가 부족합니다 (또는 직원의 말을 거부 함). 즉, 세 가지가 모두 혼잡 해져서 혼잡의 특정 부분을 해결하는 데 적합한 언어를 더 많이 도입하게됩니다.

32 년 동안 운영되어 왔지만 여전히 많은 생명을 남은 것으로 보이는 프로그래밍 프로젝트의 예를 들어 볼 수 있습니다. 오픈 소스가 아니라 상업입니다.

핵심은 프로젝트를 위해 특별히 작성된 도메인 별 언어로 작성됩니다. 롤백을 기본 아키텍처에 통합했지만 C 코드로 컴파일 한 다음 플랫폼의 컴파일러로 컴파일하기 때문에 특히 유용합니다. 32 비트와 64 비트 변형을 포함하지 않고 그 동안 약 20 개의 플랫폼을 지원했으며 현재 그 중 6 개를 제공합니다.

C ++로 작성된 애드온이 있으며 프로젝트의 과거 책임자가 C ++ / MFC / Windows / x86이 다른 모든 아키텍처와 플랫폼을 대체 할 것이라고 확신했을 때 시작되었으므로 C ++ 작업을 제공해야했습니다. 직원을 고용 할 수 있습니다. 그가 예상대로 상황이 나오지 않았습니다.

도메인 언어 및 C ++ 외에도 개발자는 테스트 장치에 내장 된 인터프리터를 사용하여 테스트 사례를 작성하는 데 사용되는 LISP에서 작업합니다. 우리는 한 시점에서 LISP를 Java로 교체하는 것을 고려했지만 실제로는 그렇지 않은 것으로 판명되었습니다.

또한 C #으로 작성된 기본 API에 대한 래퍼도 있습니다. 고객이 요청한 경우 C #에서 응용 프로그램을 다시 작성할 수 있도록이 작업을 수행했습니다. API의 C 헤더 파일과 중요한 구성 파일을 읽고 랩퍼의 C # 코드를 작성하는 Perl 스크립트에 의해 작성됩니다. C ++에서하는 것보다 Perl에서 모든 텍스트 처리를 하는 것이 쉬웠다 .

도메인 언어는 작성 기반 빌드 시스템을 사용할 수 없기 때문에 자체 빌드 시스템이 있으며이를 필요로합니다. 유닉스 계열의 플랫폼은 쉘 스크립트, Perl 및 도메인 언어의 일부 작은 프로그램으로 작성됩니다. Windows 플랫폼 용은 배치 언어, Perl 및 도메인 언어의 동일한 작은 프로그램으로 작성됩니다. 이전 VMS 빌드 시스템은 DCL로 작성되었지만 10 년 이상 사용되지 않았습니다.

도메인 언어 용 컴파일러에는 YACC / Bison 프로그래밍이 있습니다. Objective-C ++로 작성된 Apple 플랫폼 용 테스트 코드가 있습니다. 팀의 내부 웹 사이트 중 일부 (프로젝트 결과물이 아닌 프로젝트 관리에 사용됨)는 ASP로 작성되고 다른 일부는 Perl에서 CGI 스크립트로 작성됩니다.

기본적으로 이것은 어려운 문제를 해결하기위한 프로젝트로 시작되었으므로 다른 도구보다이 작업에 더 적합한 특수 도구를 만들 가치가있었습니다. 이 팀은 프로그래밍이 사용 된 언어와 다소 독립적 인 기술이라고 생각하므로 작업을보다 쉽게하기 위해 새로운 언어를 기꺼이 사용할 것입니다. 그러나 패션은 우선 순위 목록에서 높지 않기 때문에 새로운 언어를 도입하여 과제를 세분화하지는 않습니다.

이 코드의 기능은 워크 스테이션과 서버에서 사용되는 수학적 모델링입니다 (제품을 식별하지 못하면 좀 더 자유롭게 말할 수 있습니다). 현재 약 2,500 만 LoC이며 총 팀 규모는 약 50 명입니다.

경우에 따라 특정 언어에서 가장 쉽게 액세스 할 수있는 도구 (예 : OS의 UI 툴킷)가 있습니다. 예를 들어 iOS 및 macOS에서 UIKit 및 AppKit을 사용하여 GUI 응용 프로그램을 작성하려면 Swift 또는 Objective-C로 작성하는 것이 가장 빠르고 쉬운 방법입니다. (다른 언어에는 바인딩이있을 수 있지만, 빌드하려는 최신 OS 릴리스 뒤에있을 수 있으므로 모든 기능을 제공하지는 않을 수 있습니다.)

응용 프로그램이 크로스 플랫폼 일 때, 앱의 핵심 논리는 두 언어 모두에 액세스 할 수있는 언어로 작성되며 UI / OS 관련 부분은 기본적으로 작동하는 언어로 작성됩니다.

따라서 Windows 및 macOS 응용 프로그램을 작성하는 경우 C ++로 핵심 논리를 작성하고 Windows의 UI에는 C #을, macOS의 UI에는 Swift를 사용할 수 있습니다. 코어 로직을 두 번 작성할 필요가 없으며 두 앱 등에서 서로 다른 버그 세트를 처리 할 필요가 없기 때문에 시간이 절약됩니다. 크로스 플랫폼 UI 라이브러리.

일부 프로그래밍 언어가 일부 특정 작업에 더 적합 할 수 있다는 사실 외에도 실제적인 현실이 있습니다.

실제로는 고려해야 할 두 가지 중요한 사항이 있습니다.

1. 사람들은 다른 프로그래밍 언어에 대한 경험과 관심 수준이 다릅니다. -사람들이 자신이 좋아하고 능숙한 언어로 일할 수 있도록 허용하면 상황에 따라 공통 언어를 강요하는 것보다 더 나은 결과를 얻을 수 있습니다.
2. 큰 코드베이스는 다른 사람들에 의해 오랜 기간 동안 구축되었습니다. -프로젝트에 더 적합한 언어가 나오면 전체 프로젝트를 재 작성하는 데 필요한 자금이나 자원 봉사자를 확보 할 수있는 방법이 없습니다.

물론 다음과 같이 완전히 다른 요구가있는 응용 프로그램의 특정 부분이있는 경우가 종종 있습니다.

• 컴파일 된 언어로 개발 된 성능에 민감한 영역. 예시 언어 : C ++
• 스크립팅 언어로 개발 된 저렴하고 변경하기 쉬우 며 사용자 정의가 가능한 영역. 예시 언어 : Lua.
• GUI 레이아웃. 예시 언어 : HTML
• 인스톨러. 언어 / 도구 예 : WiX.
• 짓다. 언어 / 도구 예 : 목록에 너무 많으며 대개 한 번에 여러 개가 있습니다.

또한 정교한 코드베이스에서 사용하는 도구가 많이 있으며, 그 중 많은 도구가 다른 언어로 필요한 사용자 정의 및 플러그인을 허용합니다.

이미 만들어진 올바른 다른 점 외에도 :
경험에서, 많은 언어 나 환경 결정이 의미 '당신이 망치가 있다면, 모든 것이 못처럼 보인다'에 의해 만들어진, 사람들은 익숙한 도구를 사용하는 경향이있다.

또한, 새로운 환경을 도입하거나 언어는 라이센스, 교육, 어쩌면 하드웨어에서 주요 투자하고, 생산적인 시간의 큰 손실을 함께 제공 - 각 걸릴 훈련을 설치, 구성, 조달 주를 더 큰 회사의, 그리고 당신은 기본적으로 종료 초보자 개발자들과 함께.
기본적으로 더 현대적이거나 더 적합한 환경이나 언어에 '투자'할 시간이 없으므로 더 이상 작동하지 않을 때까지 가지고있는 것을 고수합니다.

특히 귀하의 질문에 따르면, 여러 사람 / 팀이 솔루션 개발에 참여하는 경우 각 그룹은 가장 잘 알고있는 것을 고수하는 경향이 있으므로 전체 솔루션에는 잠재적으로 여러 언어가 포함되어 있으며 여러 환경에서의 개발입니다.

이 질문 (및 일부 답변)은 응용 프로그램이 모 놀리 식 코드 블록이라고 가정하는 것 같습니다. 반드시 그런 것은 아닙니다.

Stack Exchange와 같은 일반적인 웹 사이트는 실제로 서로 독립적으로 실행되는 여러 가지 서비스이며, 서로간에 일종의 메시징이 있습니다. 이러한 서비스는 각각 고유 한 강점을 가진 서로 다른 언어로 구현 될 수 있습니다.

저는 소규모 커뮤니티 은행과 신용 조합을 목표로 온라인 뱅킹 플랫폼의 작은 은색 작업을하고 있습니다. 이 플랫폼에는 웹 프런트 엔드, 데이터베이스 계층, 타사 통신 계층 등 여러 구성 요소가 있습니다. 이들은 운영 체제가 다른 여러 서버에서 실행되는 모든 독립 응용 프로그램입니다. 브라우저의 클라이언트 측에서 Javascript를 실행하고 서버 측에서 Perl 페이지를 작성하고 C ++로 작성된 여러 서비스가 Perl 코드와 은행의 핵심 프로세서 사이의 추상화 계층으로 작동합니다. 다양한 계층 간 메시지 라우팅, C ++ 응용 프로그램 및 Perl 스크립트로 다양한 프로세스의 상태를 모니터링하고 상태를 내부 모니터 등에보고하는 등

모 놀리 식 응용 프로그램은 여전히 ​​존재하지만 다른 이유로도 다른 언어를 활용할 수 있습니다. Java로 애플리케이션의 90 %를 작성할 수 있지만 JNI를 사용하여 성능에 더 중요한 섹션에 C 또는 C ++를 활용하십시오.

나는 '다른 언어는 다른 강점을 가지고 있습니다'라는 주제의 매우 구체적인 사례를 지적하고 싶습니다 : FORTRAN.

Fortran은 원래 엔지니어가 수치 분석 작업을보다 쉽게 ​​수행 할 수 있도록 개발되었으며 Fortran 컴파일러가 매우 효율적인 수치 코드를 생성하도록 많은 노력을 기울였습니다. 다른 한편으로, 그 초기부터 컴퓨터의 사용은 수천 가지 방향으로 폭발 해 왔으며, 그 중 어느 것도 수치 분석과 관련이 없었으며, 프로그래밍 언어의 개발은 '실제'세계를 무시하는 데 크게 적합했습니다 [말장난을 용서].

SO : 그것은 오늘, 당신은 자신이 (말) 자바로 작성된 그것의 대부분은, 상당히 거대한 제품을 가진 회사에 근무 찾아 (내가 여기에 개인적인 경험에서 말한다) . 그러나 제품의 핵심 기능 중 하나는 어떤 형태의 수치 분석을 필요로하며 해당 특정 분석에 대한 모든 최고의 코드는 이미 Fortran에서 사용할 수 있습니다. 그래서 당신은 무엇을합니까? 이러한 포트란 코드 중 하나를 다운로드하고 해당 인터페이스 (예 : 최상위 서브 루틴의 인수)를 파악한 후 JNI 랩퍼를 C로 채운 후 Java 클래스로 패키지하십시오. 밤! 한 번에 3 개 언어로 개발해야했습니다. [특히 포트란 코드가 COMMON 블록 (예 : 정적 스토리지)을 사용하고 스레드 안전성을 위해 수정되어야하는 경우]

프로그래밍은 하나의 작업이 아니기 때문입니다. 제품을 만드는 것조차 하나의 작업이 아닙니다. 다른 언어로 가장 잘 표현되는 여러 유형의 작업이 있습니다.

좀 더 구체적으로 만들기 위해 독립형 앱과 같은 간단한 것을 가정 해 봅시다 (분산 앱에 대해 더 많은 작업이 수행되어야 함).

제품은

• 쓴
• 종합 (이것은 배포를 위해 이미지, 글꼴 등과 같은 리소스의 컴파일 및 수집을 포함합니다)
• 배치
• 구성된
• 모니터링

제품의 런타임을 작성하는 데 도움이 될 수있는 언어는 제품을 조합하는 데 적합하지 않을 수 있습니다. 등등.

그러나 제품 작성 프로세스조차도 한 언어로 최적으로 수행되지 않을 수 있습니다.

제품에서 처리되는 많은 구조화 된 데이터가 있다고 가정 해 봅시다. 글을 쓰는 시점에 데이터의 구조가 알려져 있습니까? 이 경우 배포시 일부 데이터베이스를 구성해야합니다. 이는 런타임에 컴파일되는 언어를 생성 할 수있는 언어로 최적으로 수행됩니다.

데이터 구조가 수시로 변경 될 수 있다면 어떨까요? 새로운 데이터 구조를 코드 및 데이터베이스 구성으로 전환하는 체계적인 방법이 필요합니다. 이것은 다른 언어로 수행하는 것이 가장 좋습니다.

모두 같은 언어로 할 수 있습니까? 확실한. 그러나 효과는 프로젝트를 얼마나 빨리 완료 할 수 있고 변경에 얼마나 탄력적인지에 따라 결정됩니다. 이미 존재하는 도구를 사용하여 많은 작업을 자동화 할 수 있다면 2 일 안에 다른 사람이 3 개월이 걸리는 작업을 수행 할 수 있습니다. 그러나 누군가는 다른 언어를 사용하여 반복을 통해 할 일을 자동화하고있을 것입니다.

동일한 프로젝트에서 다른 프로그래밍 언어를 사용할 수 있는 시점까지 소프트웨어 개발이 진행되었으며 이를 작동시킬 수 있습니다.

그런 다음 왜 둘 이상의 언어를 사용 하는지에 대한 의문이 있습니다.

한 가지 이유는 언어가 구식이되어 서서히 새로운 언어로 대체되기 때문입니다. 운이 좋으면 조금씩 할 수 있습니다. 따라서 프로젝트에는 기존 언어와 새로운 언어가 혼합되어 있습니다.

또 다른 이유는 언어 X가 플랫폼 A에서 사용되는 언어, 언어 Y가 플랫폼 B에서 사용되는 언어, 언어 Z가 두 플랫폼에서 모두 지원되는 상황입니다. 따라서 공통 코드는 언어 Z로 작성된 다음 플랫폼에 따라 X 또는 Y와 결합됩니다.

그리고 사람들은 다른 사람들이 작성한 코드 (즉, 스스로 작성하기 위해 시간을 소비 할 필요가없는 코드)를 사용하는 것을 좋아합니다. 다른 언어로 작성된 코드를 자유롭게 사용하고 원하는 언어로 코드를 추가 할 수 있습니다.