Khi nào sử dụng ngôn ngữ kịch bản trong một chương trình lớn hơn sẽ hữu ích?

Tôi đã nghe nói về một số tình huống của những người sử dụng say, JavaScript hoặc Python (hoặc một cái gì đó), bên trong một chương trình được viết bằng C #. Khi nào sử dụng một ngôn ngữ như JavaScript để làm một cái gì đó trong chương trình C # sẽ tốt hơn thì chỉ cần làm nó trong C #?

Khi bạn có hành vi mà bạn không muốn phải biên dịch lại chương trình để thay đổi. Đây chính xác là lý do tại sao rất nhiều trò chơi sử dụng Lua làm ngôn ngữ kịch bản / sửa đổi.

Kỹ thuật này có thể được sử dụng để thực hiện logic cốt lõi có thể dễ dàng di chuyển giữa các môi trường ngôn ngữ khác nhau. Ví dụ: tôi có một trình giả lập máy tính trong đó tất cả logic máy tính bên trong được triển khai bằng JavaScript 100%. Mã giao diện người dùng tất nhiên là khác nhau đối với mỗi nền tảng:

• Trình duyệt web (JavaScript)
• iOS (Mục tiêu-C)
• Windows (C ++ với Qt)
• Mac OS X (C ++ với Qt)
• Xoay Java (Java)

Với sự sắp xếp này, việc tạo các phiên bản chương trình của tôi cho các môi trường hoạt động khác nhau và đặc biệt là cập nhật chúng, đơn giản hơn nhiều.

Rất rộng, có hai tình huống bạn sẽ áp dụng mô hình này:

1. Điều này được sử dụng nội bộ để tận dụng một số chất lượng của ngôn ngữ nhúng.
2. Điều này được sử dụng để cung cấp khả năng lập trình bên ngoài.

Nội bộ

• Thông thường, ngôn ngữ nhúng được diễn giải cho phép thay đổi được thực hiện và kiểm tra nhanh chóng mà không cần biên dịch lại.
• Ngôn ngữ nhúng có thể biểu cảm hơn ngôn ngữ mà ứng dụng cốt lõi của bạn được viết, một lần nữa cho phép phát triển nhanh hơn.
• Ngôn ngữ có thể phù hợp hơn với một số miền cụ thể so với ngôn ngữ có mục đích chung.
• Ngôn ngữ được sử dụng bởi người dùng nội bộ, những người cần một ngôn ngữ / môi trường lập trình "đơn giản hơn". Các chương trình ngắn được viết bởi những người không phải là nhà phát triển phần mềm sử dụng cú pháp / API tương đối đơn giản.

Một ví dụ ở đây sẽ là Lua được sử dụng trong Adobe Lightroom.

Vì vậy, những gì chúng ta làm với Lua về cơ bản là tất cả logic ứng dụng từ việc chạy UI đến quản lý những gì chúng ta thực sự làm trong cơ sở dữ liệu. Gần như mọi đoạn mã trong ứng dụng có thể được mô tả là đưa ra quyết định hoặc triển khai các tính năng đều có trong Lua cho đến khi bạn bắt đầu xử lý thô, trong C ++. ( Phỏng vấn Mark Hamburg: Adobe Photoshop Lightroom )

Bên ngoài

• Cho phép người dùng mở rộng hành vi của ứng dụng của bạn mà không yêu cầu công cụ đặc biệt và / hoặc thư viện và / hoặc truy cập vào mã nguồn của bạn.
• Cung cấp cho những người dùng đó một API được xác định rõ ràng và một môi trường có hộp cát. Điều này cũng có thể được thực hiện bằng ngôn ngữ của ứng dụng nhưng việc nhúng một trình thông dịch có thể làm cho việc này dễ dàng hơn.

IBM đã sử dụng các ngôn ngữ kịch bản rất thành công trong hệ điều hành máy tính lớn VM-CMS của họ . EXEC , EXEC / 2 và sau đó Rexx đã được sử dụng trên toàn hệ thống cả bên trong lẫn bên ngoài. Các ứng dụng khác nhau (ví dụ XEDIT ) có thể được tạo tập lệnh bằng các ngôn ngữ đó và các ứng dụng / tiện ích nội bộ (ví dụ E-mail) được viết bằng ngôn ngữ kịch bản và thúc đẩy sự tích hợp chặt chẽ với HĐH và các công cụ khác. Khách hàng đã tạo và chia sẻ nhiều công cụ và ứng dụng theo kịch bản. DEC cũng cung cấp DCL . Sau này, Microsoft đã hỗ trợ VBscript làm ngôn ngữ kịch bản trong hầu hết các ứng dụng của họ và gần đây là PowerShell(còn MS / DOS batch file). Shell Unix cũng có kịch bản .

Xu hướng ngày nay dường như đang phơi bày các API theo một cách nào đó và để lại sự lựa chọn ngôn ngữ kịch bản cho những người dùng có thể sử dụng các ràng buộc khác nhau hoặc các phương tiện khác để truy cập API.

Các ví dụ trong thế giới thực sẽ bao gồm: -

• Hầu hết các trình duyệt web sẽ hỗ trợ JavaScript nhúng.

• Microsoft Office Suite - Excel Word, v.v ... tất cả đều hỗ trợ các tập lệnh VBA nhúng.

• Nhiều bộ định tuyến mạng bao gồm API tập lệnh, bằng nhiều ngôn ngữ TCL, Perl, Lua.

Nhiều thiết bị nhúng được triển khai bằng cách sử dụng một tập hợp rất nhỏ các hàm C lõi được dán lại với nhau bằng ngôn ngữ kịch bản như Lua. Vì vậy, bạn có một tập hợp các hàm C nhỏ, nhanh, tương tác với phần cứng và, hầu hết logic điều khiển theo ngôn ngữ kịch bản linh hoạt, dễ sửa đổi.

Đôi khi kịch bản được nhúng trong một ứng dụng vì đó là phương tiện để mở rộng ứng dụng máy chủ của các nhà phát triển khác. Để nắm bắt càng nhiều kỹ năng ngôn ngữ lập trình càng tốt, nhiều ngôn ngữ kịch bản có thể được máy chủ hỗ trợ. Ví dụ, trên JVM, bạn có thể nhúng một loạt các ngôn ngữ tuân thủ JSR-223 , bao gồm Python, Ruby, JavaScript, v.v.

Một lý do khác chưa được đề cập là ngôn ngữ nhúng có một hoặc nhiều tính năng nổi bật mà ngôn ngữ máy chủ không thể dễ dàng lặp lại. Một ví dụ về điều này sẽ là chức năng Parse hoặc tạo DSL dễ dàng (ngôn ngữ / ngôn ngữ cụ thể của miền) có thể được tìm thấy trong một ngôn ngữ như Rebol.

Có một cách thú vị để sử dụng ngôn ngữ kịch bản trong một ứng dụng chưa được đề cập bởi những người khác.

Nếu ngôn ngữ máy chủ của bạn có thời gian chạy phản xạ phong phú, thường rất hữu ích khi nhúng một ngôn ngữ đơn giản với REPL trong các ứng dụng của bạn, móc nó vào một ổ cắm và cấp cho nó quyền truy cập vào toàn bộ hệ thống.

Nó có thể được sử dụng để gỡ lỗi tương tác (và nó mạnh hơn nhiều so với trình gỡ lỗi thông thường của bạn), vá mã nóng, các mục đích giám sát khác nhau, thậm chí là hoạt động ngược (nếu bạn không tốt).

Tình huống cụ thể của tôi, khi tôi sử dụng ngôn ngữ kịch bản diễn giải trong một ứng dụng chính:

Có một thiết bị bên ngoài thực hiện một số chức năng. Đo lường, kiểm soát, đọc. Bản thân nó khá "ngu ngốc" và yêu cầu kiểm soát chính xác, từng bước, bao gồm rất nhiều trạng thái chờ đợi và đưa ra quyết định đột xuất về phía cơ chế kiểm soát.

Các chức năng khác nhau của thiết bị được yêu cầu tại các điểm khác nhau của ứng dụng chính, tại các thời điểm khác nhau, thường theo yêu cầu. Ứng dụng chính không cho phép các trạng thái chờ như vậy, mọi thứ phải được thực hiện với các máy trạng thái hữu hạn.

Bây giờ bất cứ ai đã viết một máy trạng thái hữu hạn đều biết việc thực hiện trạng thái chờ là có hiệu quả ít nhất hai, thường là ba hoặc bốn trạng thái bên trong của máy. Việc thực hiện hai mươi trạng thái chờ cho các chức năng khác nhau (và chờ phản hồi của chúng và phản ứng tương ứng) của thiết bị bên ngoài sẽ là một trải nghiệm rất, rất bực bội.

Vì vậy, thay vào đó là các trạng thái "thực thi chức năng không chờ", "thực thi chức năng chặn", "thực hiện chức năng phân nhánh / điều kiện / nhảy" trong máy trạng thái hữu hạn, có thể là tổng cộng sáu trạng thái. Và có các kịch bản điều khiển được lên lịch để thực hiện, sau đó được trình thông dịch điều khiển thiết bị bên ngoài thực hiện và kết quả của chúng được đặt ở nơi chúng được yêu cầu.

Tóm tắt, ứng dụng: trong RTOS, sử dụng ngôn ngữ kịch bản được diễn giải nội bộ có thể làm giảm đáng kể sự phức tạp của việc thực hiện các tác vụ phong phú ở trạng thái chờ (chức năng chặn).

Từ kinh nghiệm của tôi, chúng tôi đã từng phát triển một ứng dụng lớn viết lại mã nguồn của một langue "cổ đại" để tương thích unicode. Điều này đã được thực hiện trong C #. Cuối cùng tôi chỉ viết công cụ (tạo mô hình dữ liệu và cung cấp phương tiện để thực hiện các bước cần thiết cho quy trình viết lại) trong C # - "mã keo" để thực hiện mọi thứ được thực hiện trong IronPython.

Điểm lớn nhất cho IronPython tích hợp: Giả sử bạn đã tải một mô hình dữ liệu lớn (thời gian tải khoảng một giờ). Sau đó, bạn muốn - thu thập thông tin một cách thủ công và tìm kiếm mọi thứ. Làm điều này với tập lệnh Python từ bảng điều khiển tương tác tốt hơn nhiều so với nhấp qua mô hình dữ liệu bằng trình gỡ lỗi (cộng với, nó có thể phát lại).

Có vài lý do.

• Đường cong học tập. Hầu như mọi người đều có thể học và viết bằng javascript.
• Bảo vệ. Thật khó để kiểm soát bối cảnh bảo mật của mã tập lệnh trong C # hoặc Java. Javascript là hoàn hảo cho điều đó. Tác giả kịch bản không bao giờ có thể truy cập vào đĩa hoặc bất cứ nơi nào nếu không cho phép chúng. Công cụ javascript lõi chỉ là một máy tính nâng cao.
• Chất lượng. Bạn đặt một giới hạn rất dày cho mã script. Các cấp độ "mã Spaghetti" rất khác nhau đối với Javascript hoặc C # / Java. (Điều này ngăn bạn mở cổng địa ngục)
• Loại an toàn. C # / Java là môi trường an toàn kiểu, bạn hầu như không thích nó trong môi trường tập lệnh. Biểu thức như "12" + 3 cho "123" trong javascript nhưng C # / Java thậm chí sẽ không biên dịch. Các tác giả kịch bản hầu như không biết "kiểu" là gì
• Năng động. Bất kỳ đối tượng nào cũng có thể chứa bất kỳ thuộc tính / phương thức nào và có thể thay đổi loại thời gian. Ví dụ, tôi có thể cung cấp một đối tượng C # proxy cho môi trường tập lệnh hiển thị các nút XML dưới dạng các thuộc tính.
• Năng suất. Thông thường viết script dễ hơn nhiều so với C # / Java. Không cần biên dịch hoặc "đăng ký plugin". Bạn có thể trực tiếp chỉnh sửa nội dung tập lệnh trong ứng dụng với kết quả ngay lập tức.
• Quản lý. Sử dụng C # / Java yêu cầu SDK phải được liên kết trên các plugin hiển thị các lớp bên trong ra thế giới. Kiến trúc plugin này yêu cầu "khả năng tương thích ngược" cho các phiên bản SDK cũ. Kiến trúc này buộc bạn phải tạo các đối tượng miền "ảo" cung cấp cơ chế ứng dụng bên trong trong ngữ cảnh miền. Nó dễ quản lý / linh hoạt hơn so với việc hiển thị API.

Khi nào? Từ năm 1948 đến 2008 - các ngôn ngữ được biên dịch ban đầu đã mất thời gian đáng kể để biên dịch và liên kết, do đó, việc tạo ra một ngôn ngữ kịch bản để cho phép người dùng tùy chỉnh và cấu hình là điều phổ biến. Nếu bạn nhìn vào lịch sử của AutoLisp, thì câu trả lời ban đầu là AutoCAD được cung cấp với ngôn ngữ kịch bản bên trong nó, nhưng điều này đã được loại bỏ để ủng hộ việc hiển thị giao diện có thể script cho VBA sau đó .net.

Với CLR, việc kích hoạt chương trình C # hoặc chương trình Lua vào hệ thống hiện có không khác biệt đáng kể về chi phí phát triển và thời gian chạy .net có các công cụ để tạo và biên dịch nhanh chóng.

Bạn không còn cần phải có ngôn ngữ kịch bản trong chương trình lớn hơn, mà thay vào đó, hãy hiển thị chương trình lớn hơn cho các phương tiện kịch bản lệnh của thời gian chạy.

Trong các môi trường không cung cấp quá trình tạo và biên dịch mã bay, và nó được coi là mong muốn cung cấp ngôn ngữ tự động hóa cho mục đích chung thay vì ngôn ngữ cụ thể cho miền, bạn vẫn sẽ nhận được kịch bản lệnh Lua hoặc Python. Đối với các công cụ cung cấp giao diện COM, thì ngôn ngữ kịch bản lệnh đó sẽ là C # hoặc VB.net (MS Office, Sparx Enterprise Architect). Vì vậy, có một ngôn ngữ kịch bản cho một chương trình được viết bằng ngôn ngữ đủ đơn giản để trở thành ngôn ngữ kịch bản là không cần thiết.