Bir betik dilini daha büyük bir programda kullanmak ne zaman faydalı olur?

C # ile yazılmış bir programın içinde JavaScript, Python (veya benzeri) kullanan birçok insan durumunu duydum. Bir C # programında bir şey yapmak için JavaScript gibi bir dili ne zaman kullanmak daha sonra C # ile yapmak daha iyi olur?

Davranışlarınız olduğunda, programı değiştirmek için programı tekrar derlemek zorunda kalmazsınız. İşte bu yüzden birçok oyun Lua'yı kodlama / kodlama dili olarak kullanıyor.

Bu teknik, farklı dil ortamları arasında kolayca taşınabilir çekirdek mantığı uygulamak için kullanılabilir. Örneğin, tüm dahili hesap makinesi mantığının% 100 JavaScript'te uygulandığı bir hesap makinesi simülatörüne sahibim . Kullanıcı arayüzü kodu her platform için elbette farklıdır:

• Web tarayıcısı (JavaScript)
• iOS (Amaç-C)
• Windows (C ++ ile Q ++)
• Mac OS X (Qt ile C ++)
• Java Salıncak (Java)

Bu düzenleme ile programımın farklı işletim ortamları için versiyonlarını yapmak ve özellikle güncel tutmak çok daha kolay.

Genel olarak bu modeli uygulayabileceğiniz iki durum var:

1. Bu, dahili dilin bazı kalitesini artırmak için dahili olarak kullanılır.
2. Bu harici programlanabilirliği sağlamak için kullanılır.

içten

• Tipik olarak gömülü dil, derleme yapılmadan değişikliklerin hızlı bir şekilde yapılmasını ve test edilmesini sağlayan yorumlanır.
• Gömülü dil, çekirdek uygulamanızın yazıldığı dilden daha anlamlı olabilir ve daha hızlı bir gelişim sağlar.
• Dil, genel amaçlı bir dile kıyasla, belirli bir etki alanı için daha uygun olabilir .
• Dil, "daha basit" bir programlama diline / ortamına ihtiyaç duyan dahili kullanıcılar tarafından kullanılır. Kısa programlar, nispeten basit bir sözdizimi / API kullanan yazılım geliştiricisi olmayan kişiler tarafından yazılır.

Buradaki bir örnek, Adobe Lightroom'da kullanılan Lua olabilir.

Yani Lua ile yaptığımız şey aslında UI'nın çalıştırılmasından veritabanında gerçekte ne yaptığımızı yönetmeye kadar tüm uygulama mantığıdır. Karar verme veya özellikleri uygulama olarak tanımlanabilecek uygulamadaki her kod parçası hemen hemen C ++ 'da işlenene kadar Lua’dadır. ( Mark Hamburg Röportajı: Adobe Photoshop Lightroom )

haricen

• Kullanıcıların özel takım ve / veya kitaplıklar ve / veya kaynak kodunuza erişmesine gerek kalmadan uygulamanızın davranışını genişletmesine izin verin.
• Bu kullanıcılara iyi tanımlanmış bir API ve korumalı alan ortamı sağlayın. Bu, uygulamanın dilinde de yapılabilir ancak bir tercümanın gömülmesi bunu daha kolay hale getirebilir.

IBM, ana bilgisayar işletim sistemi VM-CMS'de komut dosyası dillerini çok başarılı bir şekilde kullandı . EXEC , EXEC / 2 ve daha sonra Rexx hem dahili hem de harici olarak sistem boyunca kullanılmıştır. Aynı uygulamalar kullanılarak farklı uygulamalar (örneğin XEDIT ) yazılabilir ve iç uygulamalar / yardımcı programlar (örn. E-posta) kodlama dilinde yazılmıştır ve işletim sistemi ve diğer araçlarla sıkı entegrasyondan yararlanılmıştır. Müşteriler pek çok komut dosyası araçları ve uygulaması oluşturdu ve paylaştı. DEC ayrıca DCL sağladı . Daha sonra Microsoft, VBscript'i uygulamalarının çoğunda bir betik dili olarak ve daha yakın zamanda PowerShell'i destekledi(ayrıca MS / DOS toplu iş dosyaları). Unix kabukları da komut dosyası içeriyor .

Bugünkü eğilim API'leri bir şekilde ortaya koyuyor gibi görünüyor ve farklı bağlamalar veya API'ye erişmenin başka yollarını kullanabilen kullanıcılara yönelik komut dosyası dili seçimini bırakıyor gibi görünüyor.

Gerçek dünya örnekleri şunları içerir: -

• Katıştırılmış JavaScript'i destekleyecek çoğu web tarayıcısı.

• Microsoft Office Suite - Excel Word vb. Tümleşik VBA komut dosyalarını destekler.

• Birçok ağ yönlendiricisi çeşitli dillerde TCL, Perl, Lua komut dosyası API'leri içerir.

Birçok gömülü aygıt, Lua gibi bir betik dili kullanılarak birbirine yapıştırılan çok küçük bir çekirdek C işlevi kümesi kullanılarak uygulanır. Böylece, donanımla etkileşime giren bir dizi küçük, hızlı C işlevine ve kontrol mantığının çoğuna esnek, değiştirilmesi kolay bir komut dosyası diliyle ulaşabilirsiniz.

Bazen komut dosyası bir uygulamaya gömülüdür, çünkü bu ana bilgisayar uygulamasını diğer geliştiriciler tarafından genişletmenin bir yoludur. Mümkün olduğunca çok sayıda programlama dili becerisini yakalamak için, ana bilgisayar tarafından birden fazla komut dosyası dili desteklenebilir. Örneğin, JVM'de Python, Ruby, JavaScript, vb. Dahil olmak üzere tüm JSR-223 uyumlu dillerin bir bölümünü gömebilirsiniz .

Daha önce belirtilmeyen bir başka neden de, gömülü dilin, ana dilin kolayca kopyalayamadığı bir veya daha fazla göze çarpan özelliğe sahip olmasıdır. Bunun bir örneği, Rebol gibi bir dilde bulunabilecek Ayrıştırma işlevi veya zahmetsiz DSL (etki alanına özgü dil / lehçe) oluşturma olabilir.

Diğerleri tarafından henüz belirtilmeyen bir uygulamanın içinde kodlama dili kullanmanın ilginç bir yolu vardır.

Ana diliniz zengin, yansıtıcı bir çalışma süresine sahipse, uygulamalarınıza REPL ile basit bir dil yerleştirmek, bir prize takmak ve tüm sisteme erişim vermek genellikle yararlıdır.

Etkileşimli bir hata ayıklama için kullanılabilir (ve doğal olarak her zamanki hata ayıklayıcınızdan çok daha güçlüdür), sıcak kod düzeltme eki, çeşitli izleme amaçları, hatta arka kapalı ortamlar (eğer iyi değilseniz).

Özel durumum, büyük bir uygulamada yorumlanmış bir betik dili kullandığımda:

Birkaç işlevi gören harici bir cihaz var. Ölçümler, kontrol, okumalar. Kendisi oldukça "aptal" ve kontrol mekanizması tarafında çok sayıda bekleme durumu ve geçici karar verme dahil olmak üzere adım adım hassas kontrol gerektiriyor.

Cihazın çeşitli işlevsellikleri, ana uygulamanın çeşitli noktalarında, farklı zamanlarda, sıklıkla talep üzerine gereklidir. Ana uygulama böyle bekletme durumlarına izin vermiyor, her şey sonlu durumlu makinelerle yapılmalı.

Şimdi, sonlu durumlu bir makine yazan kişi, bekleme durumunun uygulanmasının, makinenin en az iki, genellikle üç veya dört iç durumunun etkili olduğunu bilir. Harici cihazın yirmi bekletme durumunun çeşitli fonksiyonlara uygulanması (ve cevaplarını beklemek ve buna göre tepki vermek) çok, çok sinir bozucu bir deneyim olacaktır.

Dolayısıyla, bunun yerine, sonlu durumlu makinede "beklemesiz bir fonksiyon yürütme", "bir engelleme fonksiyonunu çalıştırma", "bir dallanma / koşullu / atlama" fonksiyonunun durumları, toplamda altı durum vardır. Ve yürütme için planlanan, sonra harici aygıtı kontrol eden tercüman tarafından yürütülen kontrol komut dosyaları ve sonuçları, gerektiğinde yerleştirilir.

Özetle, uygulama: bir RTOS'da, dahili bir yorumlanmış betik dili kullanmak, bekleme durumlarında (engelleme fonksiyonları) bol miktarda görev yerine getirme karmaşıklığını büyük ölçüde azaltabilir.

Tecrübelerime göre, bir zamanlar "eski" bir dilimin kaynak kodunu unicode uyumlu olacak şekilde yeniden yazan büyük bir uygulama geliştirdik. C # ile yapıldı. C # 'da sadece motoru (bir veri modeli oluşturur ve yeniden yazma işlemi için gerekli adımları atmanın yollarını sağlar) yazdım.

Entegre IronPython için en büyük nokta: Büyük bir veri modeli yüklediğinizi varsayalım (yaklaşık bir saatlik yükleme süresi). O zaman - manüel olarak - bilgi toplamak ve bir şeyler aramak istersiniz. Bunu interaktif bir konsoldan bir Python betiği ile yapmak, hata ayıklayıcı ile veri modeline tıklamaktan çok daha iyidir (artı, kopyalanabilir).

Bunun birkaç nedeni var.

• Öğrenme eğrisi. Neredeyse herkes javascript ile öğrenip yazabilir.
• Güvenlik. C # veya Java'daki kod kodunun güvenlik bağlamını kontrol etmek zordur. Javascript bunun için idealdir. Senaryo yazarı, izin vermediği sürece diske veya herhangi bir yere asla erişemez. Çekirdek javascript motoru sadece gelişmiş bir hesap makinesidir.
• Kalite. Senaryo koduna çok kalın bir limit koydun. "Spagetti kodu" seviyeleri Javascript veya C # / Java için çok farklı. (Cehennemin kapısını açmanı engelleyen)
• Güvenliği yazın. C # / Java, güvenli bir ortamdır, çoğunlukla bir komut dosyası oluşturma ortamında tercih etmiyorsunuz. "12" + 3 gibi bir ifade javascript'te "123" verir, ancak C # / Java bile derlenmez. Senaryo yazarları çoğunlukla "tür" olanları bile yapmazlar
• Dinamik. Herhangi bir nesne herhangi bir özellik / yöntem içerebilir ve zaman içinde türünü değiştirebilir. Örneğin, XML düğümlerini özellik olarak gösteren komut dosyası oluşturma ortamına bir proxy C # nesnesi sağlayabilirim.
• Üretkenlik. Genellikle senaryo yazmak C # / Java'dan çok daha kolaydır. Derleme veya "eklenti kaydı" gerekmez. Uygulama içindeki komut dosyası içeriğini doğrudan sonuçlarla doğrudan düzenleyebilirsiniz.
• Yönetme. C # / Java'yı kullanmak, dahili sınıfları dünyaya açan eklentiler üzerinde bir bağlantı olmasını gerektirir. Bu eklenti mimarisi eski SDK sürümleri için "geriye dönük uyumluluk" gerektirir. Bu mimari, sizi etki alanı bağlamında iç uygulama mekanizması sağlayan "sanal" etki alanı nesneleri oluşturmaya zorlar. Bir API'yi ortaya koymaktan daha yönetilebilir / esnektir.

Ne zaman? 1948 ve 2008 arasında - başlangıçta derlenmiş dillerin derlenmesi ve bağlanması çok zaman aldı, bu nedenle kullanıcının özelleştirmesini ve yapılandırılmasını sağlamak için bir betik dili oluşturmak olağandı. AutoLisp'in geçmişine bakarsanız, cevap başlangıçta AutoCAD içinde bir betik dili ile birlikte gönderilir, ancak bu VBA'ya.

CLR ile, bir C # programının veya bir Lua programının çağrısının mevcut bir sisteme çağrılması, geliştirme maliyetinde önemli bir farklılık göstermez ve .net çalışma zamanı, anında oluşturma ve derleme için kullanılan araçlarla birlikte gelir.

Artık bir kodlama dili olması gerekir dahilinde büyük bir programın, ancak bunun yerine çalışma zamanı komut dosyası tesislerine büyük bir program maruz.

Sineklik kodu oluşturma ve derleme özelliği sunmayan ve etki alanına özgü bir alandan ziyade genel amaçlı bir otomasyon dili sunmanın istendiği görülüyorsa, yine de Lua veya Python komut dosyası alacaksınız. Bir COM arayüzü sunan araçlar için, bu komut dosyası dili C # veya VB.net (MS Office, Sparx Enterprise Architect) olacaktır. Bu yüzden, bir betik dili olmak için yeterince basit bir dilde yazılmış bir program için bir betik dili kullanmak gereksizdir.