더 큰 프로그램에서 스크립팅 언어를 사용하는 것이 언제 유용한가요?

C #으로 작성된 프로그램에서 JavaScript 또는 Python (또는 무언가)을 사용하는 사람들의 여러 상황에 대해 들었습니다. JavaScript와 같은 언어를 사용하여 C # 프로그램에서 무언가를 수행하는 것이 C #에서 수행하는 것보다 낫습니까?

동작이 변경 될 때 프로그램을 다시 컴파일 할 필요가없는 경우 이것이 바로 많은 게임이 Lua를 스크립팅 / 모딩 언어로 사용하는 이유입니다.

이 기술은 다른 언어 환경간에 쉽게 이식 할 수있는 핵심 논리를 구현하는 데 사용할 수 있습니다. 예를 들어, 모든 내부 계산기 논리가 100 % JavaScript로 구현 되는 계산기 시뮬레이터 가 있습니다. 사용자 인터페이스 코드는 물론 각 플랫폼마다 다릅니다.

• 웹 브라우저 (자바 스크립트)
• iOS (Objective-C)
• Windows (Qt 포함 C ++)
• Mac OS X (Qt 포함 C ++)
• 자바 스윙 (자바)

이 배열을 사용하면 다른 운영 환경에 맞는 프로그램 버전을 만들고 특히 최신 버전을 유지하는 것이 훨씬 간단합니다.

이 패턴을 적용 할 상황은 매우 광범위합니다.

1. 이것은 내장 언어의 일부 품질을 활용하기 위해 내부적으로 사용됩니다.
2. 외부 프로그래밍 기능을 제공하는 데 사용됩니다.

내부적으로

• 일반적으로 임베디드 언어가 해석되어 재 컴파일없이 변경을 신속하게 수행하고 테스트 할 수 있습니다.
• 내장 된 언어는 핵심 응용 프로그램이 작성된 언어보다 표현력이 뛰어나 더 빠른 개발을 가능하게합니다.
• 이 언어는 범용 언어에 비해 특정 도메인에 더 적합 할 수 있습니다.
• 이 언어는 "더 간단한"프로그래밍 언어 / 환경이 필요한 내부 사용자가 사용합니다. 짧은 프로그램은 비교적 간단한 구문 / API를 사용하는 소프트웨어 개발자가 아닌 사람들이 작성합니다.

여기에 Adobe Lightroom에서 사용되는 Lua가 있습니다.

우리가 Lua로하는 것은 본질적으로 UI 실행에서 실제로 데이터베이스에서하는 일을 관리하는 것까지 모든 애플리케이션 로직입니다. 의사 결정을 내리거나 기능을 구현하는 것으로 설명 할 수있는 앱의 거의 모든 코드는 C ++의 원시 처리에 도달 할 때까지 Lua에 있습니다. ( Mark Hamburg 인터뷰 : Adobe Photoshop Lightroom )

외부 적으로

• 사용자는 특별한 툴링 및 / 또는 라이브러리 및 / 또는 소스 코드에 대한 액세스없이 애플리케이션의 동작을 확장 할 수 있습니다.
• 이러한 사용자에게 잘 정의 된 API와 샌드 박스 환경을 제공하십시오. 이것은 응용 프로그램의 언어로도 가능하지만 통역사를 포함하면 이것을 쉽게 할 수 있습니다.

IBM은 메인 프레임 운영 체제 VM-CMS 에서 스크립팅 언어를 매우 성공적으로 사용했습니다 . EXEC , EXEC / 2 이상 Rexx 는 시스템 전체에서 내부 및 외부 적으로 사용되었습니다. 다른 응용 프로그램 (예 : XEDIT )은 동일한 언어를 사용하여 스크립팅 할 수 있었고 내부 응용 프로그램 / 유틸리티 (예 : 전자 메일)는 스크립팅 언어로 작성되었으며 OS 및 기타 도구와의 긴밀한 통합을 활용했습니다. 고객은 많은 스크립트 도구와 응용 프로그램을 만들고 공유했습니다. DEC는 DCL 도 제공했습니다 . 나중에 Microsoft 는 대부분의 응용 프로그램 및 더 최근에는 PowerShell 에서 VBscript 를 스크립팅 언어로 지원 했습니다.(또한 MS / DOS 배치 파일). 유닉스 쉘에는 스크립팅 도 있습니다.

오늘날 트렌드는 어떤 방식 으로든 API를 노출하고 있으며 다른 바인딩을 사용하거나 API에 액세스하는 다른 수단을 사용할 수있는 사용자에게 스크립팅 언어를 선택할 수있게합니다.

실제 예는 다음과 같습니다.

• 임베디드 JavaScript를 지원하는 대부분의 웹 브라우저.

• Microsoft Office Suite-Excel Word 등은 모두 포함 된 VBA 스크립트를 지원합니다.

• 많은 네트워크 라우터에는 다양한 언어 TCL, Perl, Lua의 스크립트 API가 포함되어 있습니다.

많은 임베디드 디바이스는 Lua와 같은 스크립팅 언어를 사용하여 서로 결합 된 매우 작은 코어 C 함수 세트를 사용하여 구현됩니다. 따라서 하드웨어와 상호 작용할 수있는 작고 빠른 C 함수 세트가 있으며 대부분의 제어 로직은 유연하고 수정하기 쉬운 스크립팅 언어로 제공됩니다.

스크립팅은 다른 개발자가 호스트 응용 프로그램을 확장하는 수단이기 때문에 응용 프로그램에 포함되는 경우가 있습니다. 가능한 광범위한 프로그래밍 언어 기술을 포착하기 위해 호스트는 여러 스크립트 언어를 지원할 수 있습니다. 예를 들어, JVM에서 Python, Ruby, JavaScript 등을 포함하여 많은 JSR-223 호환 언어 를 포함 할 수 있습니다 .

아직 언급되지 않은 또 다른 이유는 내장 언어에 호스트 언어가 쉽게 복제 할 수없는 하나 이상의 뛰어난 기능이 있기 때문입니다. 예를 들어 구문 분석 기능이나 간편한 DSL (도메인 특정 언어 / 방언) 생성이 있으며 이는 Rebol과 같은 언어에서 찾을 수 있습니다.

다른 사람이 아직 언급하지 않은 응용 프로그램 내에서 스크립팅 언어를 사용하는 흥미로운 방법이 있습니다.

호스트 언어에 리플렉션 런타임이 풍부하면 응용 프로그램에 REPL이 포함 된 간단한 언어를 포함시키고 소켓에 연결하여 전체 시스템에 액세스하는 것이 유용한 경우가 많습니다.

대화 형 디버깅 (일반적으로 디버거보다 훨씬 강력 함), 핫 코드 패치, 다양한 모니터링 목적, 백도어 (좋지 않은 경우)에도 사용할 수 있습니다.

주요 응용 프로그램에서 해석 된 스크립팅 언어를 사용할 때의 특정 상황 :

여러 기능을 수행하는 외부 장치가 있습니다. 측정, 제어, 판독. 그것은 꽤 "멍청한"자체이며 많은 대기 상태와 제어 메커니즘 측면에서의 임시 의사 결정을 포함하여 단계별로 정확한 제어가 필요합니다.

장치의 다양한 기능은 메인 애플리케이션의 다양한 시점에서 다른 시간에 종종 주문형으로 요구됩니다. 메인 앱은 대기 상태를 허용하지 않으므로 모든 것이 유한 상태 머신으로 수행되어야합니다.

이제 유한 상태 머신을 작성한 사람은 대기 상태를 구현하는 것이 적어도 2, 종종 3-4 개의 머신의 내부 상태임을 알게됩니다. 외부 장치의 다양한 기능에 대한 20 개의 대기 상태를 구현하고 이에 대한 응답을 기다리고 이에 따라 반응하는 것은 매우 실망스러운 경험이 될 것입니다.

따라서, 유한 상태 머신에는 "대기없는 기능 실행", "차단 기능 실행", "분기 / 조건부 / 점프 실행"상태가있을 수 있으며, 총 6 개의 상태 일 수 있습니다. 그리고 실행을 위해 예약 된 제어 스크립트가 있으며, 외부 장치를 제어하는 ​​인터프리터에 의해 실행되며 결과는 필요한 곳에 배치됩니다.

요약하자면, RTOS에서 내부 해석 스크립트 언어를 사용하면 대기 상태 (블로킹 기능)가 풍부한 작업을 수행하는 복잡성을 크게 줄일 수 있습니다.

내 경험으로, 우리는 한때 "고대"언어의 소스 코드를 유니 코드와 호환되도록 재 작성하는 큰 응용 프로그램을 개발했습니다. C #에서 수행되었습니다. C #에서 엔진 (데이터 모델을 작성하고 다시 쓰기 프로세스에 필요한 단계를 수행하는 수단을 제공함) 만 작성했습니다. 실제로 실제로 실행하는 "접착제 코드"는 IronPython에서 수행됩니다.

통합 IronPython의 가장 큰 포인트 : 빅 데이터 모델 (로드 시간 약 1 시간)을로드했다고 가정 해 봅시다. 그런 다음 정보를 수동으로 수집하고 검색합니다. 대화식 콘솔에서 Python 스크립트로이를 수행하는 것이 디버거를 사용하여 데이터 모델을 클릭하는 것보다 훨씬 좋습니다 (재생 가능).

몇 가지 이유가 있습니다.

• 학습 곡선. 거의 모든 사람이 자바 스크립트로 배우고 쓸 수 있습니다.
• 보안. C # 또는 Java에서 스크립트 코드의 보안 컨텍스트를 제어하기는 어렵습니다. 자바 스크립트는 그 점에 완벽합니다. 스크립트 작성자는 디스크 나 디스크를 허용하지 않으면 어디에서나 디스크에 액세스 할 수 없습니다. 핵심 자바 스크립트 엔진은 고급 계산기 일뿐입니다.
• 품질. 스크립팅 코드에는 매우 두꺼운 제한이 있습니다. "스파게티 코드"수준은 Javascript 또는 C # / Java에서 매우 다릅니다. (지옥의 문을 열지 못하게하는 것)
• 타입 안전. C # / Java는 형식이 안전한 환경이므로 스크립팅 환경에서는 선호하지 않습니다. "12"+ 3과 같은 표현식은 자바 스크립트에서 "123"을 제공하지만 C # / Java는 컴파일조차하지 않습니다. 스크립트 작성자는 대부분 "유형"이 아닙니다
• 동적. 모든 객체는 모든 속성 / 방법을 포함 할 수 있으며 시간에 따라 유형이 변경 될 수 있습니다. 예를 들어, XML 노드를 속성으로 노출하는 스크립팅 환경에 프록시 C # 객체를 제공 할 수 있습니다.
• 생산력. 일반적으로 스크립트 작성은 C # / Java보다 훨씬 쉽습니다. 컴파일이나 "플러그인 등록"이 필요하지 않습니다. 응용 프로그램 내에서 스크립트 내용을 직접 편집하여 즉시 결과를 얻을 수 있습니다.
• 관리. C # / Java를 사용하려면 내부 클래스를 전 세계에 노출시키는 플러그인에서 SDK가 링크되어야합니다. 이 플러그인 아키텍처에는 이전 SDK 버전에 대한 "이전 버전과의 호환성"이 필요합니다. 이 아키텍처는 도메인 컨텍스트에서 애플리케이션의 내부 메커니즘을 제공하는 "가상"도메인 객체를 생성하도록합니다. API를 노출하는 것보다 관리하기 쉽고 유연합니다.

언제? 1948 년에서 2008 년 사이 – 초기에 컴파일 된 언어는 컴파일 및 링크하는 데 상당한 시간이 걸렸으므로 사용자 지정 및 구성을 허용하는 스크립팅 언어를 만드는 것이 일반적이었습니다. AutoLisp의 히스토리를 살펴보면, 초기에 AutoCAD에 스크립팅 언어가 포함되어 있지만, 스크립트 가능한 인터페이스를 VBA에 .net에 노출시키기 위해 단계적으로 폐지되었습니다.

CLR을 사용하면 기존 시스템으로 C # 프로그램 또는 Lua 프로그램 호출을 활성화하는 데 개발 비용이 크게 다르지 않으며 .net 런타임에는 즉시 생성 및 컴파일 할 수있는 도구가 제공됩니다.

더 큰 프로그램 내에 더 이상 스크립팅 언어가 필요하지 않지만 대신 더 큰 프로그램을 런타임의 스크립팅 기능에 노출하십시오.

플라이 코드 생성 및 컴파일을 제공하지 않는 환경에서 도메인 별 언어가 아닌 범용 자동화 언어를 제공하는 것이 바람직한 것으로 보더라도 여전히 Lua 또는 Python 스크립팅을 얻을 수 있습니다. COM 인터페이스를 제공하는 도구의 경우 해당 스크립팅 언어는 C # 또는 VB.net (MS Office, Sparx Enterprise Architect)입니다. 따라서 스크립트 언어가되기에 충분히 간단한 언어로 작성된 프로그램의 스크립트 언어를 갖는 것은 불필요합니다.