Saat Anda ingin memberi pengguna kemampuan untuk menulis plugin untuk aplikasi Anda, Anda dihadapkan pada pilihan bagaimana menyediakan API. Di bawah potongan, saya akan menunjukkan mengapa solusi terburuk untuk ini adalah menciptakan bahasa pemrograman Anda sendiri dan mengurai kode sumber, serta furnitur di sini.

PL bukan fungsi utama aplikasi

Bayangkan kita membuka produksi furnitur modular. Ada beberapa elemen dasar: countertops, tatakan gelas, meja samping tempat tidur, dll. Ada jalur produksi yang terkait dengan pemrosesan kayu: peralatan mesin, gergaji, pernis, semua dengan teknologi terbaru. Tapi semua ini entah bagaimana harus disatukan. Kita tahu bahwa ada 100.500 perusahaan yang berspesialisasi dalam pembuatan perangkat keras dan baut, ada beberapa standar untuk pengencang furnitur yang telah diciptakan oleh komunitas profesional untuk membuat hidup lebih mudah bagi pelanggan mereka. Seberapa jauhkah keputusan akan mengerahkan garis tambahan untuk produksi baut, mur, dan sudut sendiri?

Apa yang bisa kita menangkan?

• Dengan cara ini, kita dapat memberi merek produk kita sehingga hamster merasakan "keasliannya" dan membawa lebih banyak uang.
• Mungkin ini akan memungkinkan kami untuk tidak membayar hak cipta untuk baut, atau untuk menyelesaikan masalah logistik.
• Kita dapat memasuki pasar baru untuk baut dan mur, menetapkan standar kita sendiri, yang lebih cepat, lebih baik, dan lebih tinggi.

Tapi mari kita bersihkan.

• Ilitisme adalah karya wiraniaga. Penjual akan atau tidak akan membuat merek menjadi Elite dengan atau tanpa lini produksi baru.
• Hak cipta, sebagai suatu peraturan (tidak selalu, tentu saja), lebih murah daripada pengembangan dari awal. Dan menyelesaikan masalah pengiriman satu elemen dengan menggunakan jalur produksi baru, Anda hanya memperburuknya.
• Jika kita ingin mencoba bidang kegiatan baru untuk diri kita sendiri, kita tidak perlu menghubungkannya dengan apa yang sudah kita lakukan. Tampaknya lebih mudah untuk mendorong baut dengan furnitur, tetapi jika baut tidak terbang, mereka akan menyeret furnitur bersama mereka. Setidaknya apa yang sudah dikenakan biaya pada klien.

Kembali ke domba kami: jika Anda membuat ekosistem untuk ekstensi aplikasi Anda, maka Anda memiliki aplikasi . Itu melakukan sesuatu yang baik, sesuatu yang Anda kuasai.

KSP - Kontakt Script Processor, atau jalur produksi baut di dunia audio digital

Saya akan bercerita tentang bahasa seperti itu kepada Anda:

Kontakt adalah romper (sampler) dari perusahaan Austria Native Instruments . Saat ini sangat sulit untuk menemukan proyek menggunakan alat virtual yang tidak digunakan. Selama 10 tahun terakhir, Kontakt telah menduduki sebagian besar pasar instrumen sampel. Rahasianya sederhana: pada suatu waktu, Kontakt mengusulkan dua inovasi yang membalikkan perkembangan instrumen virtual sampel.

Inovasi pertama berhubungan langsung dengan fungsi utamanya: ia menangani memori dengan sangat hati-hati (dan sampel dalam wav adalah pemakan yang sama, baik HDD dan RAM). NI membuat format kompresi lossless dengan decoding cepat dan menulis sistem penyangga audio revolusioner untuk masanya.

Inovasi kedua adalah KSP

Sebelum kontak, ada dua cara untuk secara fungsional mengatur sampel yang direkam ke dalam instrumen yang dikendalikan MIDI:

• Tulis mesin Anda sendiri dari awal dalam C ++, atau dalam bahasa lain yang dapat menggunakan Steinberg's VST SDK (dan ada format plugin lainnya, misalnya, AAX).
• Gunakan sampler siap pakai yang dibuat untuk musisi yang tidak terbiasa dengan pemrograman, tetapi yang memiliki suara yang perlu diatur dalam beberapa jenis sistem. Katakanlah Giga Studio . Tetapi romperm seperti itu, sebagai suatu peraturan, entah ditutup, atau untuk menyelesaikan pekerjaan mereka, mereka membutuhkan tidak kurang dari staf daripada pengembangan telanjang di bawah VST SDK.

Kontak senang baik ini dan itu: untuk pembuatan prototipe cepat ada GUI nyaman yang dapat dimengerti oleh setiap musisi yang telah membaca manual, dan untuk penyempurnaan lebih lanjut tidak ada yang kurang dari bahasa pemrograman , dengan kondisi, fungsi (dari versi 4) dan perpustakaan standar yang mewakili API untuk sebagian besar fungsi yang diterapkan melalui GUI, serta parameter untuk memutar sampel secara langsung. Antara lain, dari versi 2 menjadi mungkin untuk menyesuaikan antarmuka dengan segala macam peluit dan palsu, yang memungkinkan untuk menunjukkan keunikannya pada skala yang hampir tak terbatas. Dan kode pengembang disembunyikan dari tampilan dua kali: kebingungan dan perlindungan terhadap alat yang berubah.

Mengingat semakin populernya mesin, serta periode yang mengesankan pengembangan aktif baju monyet, hari ini Kontakt adalah jenis senapan serbu Kalashnikov di dunia Audio Digital. Mudah dipelajari, dapat diandalkan sebagai tank, memiliki kemampuan untuk dopilka dalam batas yang wajar untuk diri Anda tercinta, dan memegang pasar yang sangat besar bagi pengguna yang puas.

Tidak semuanya begitu cerah

Hal yang tak terhindarkan terjadi: inovasi dalam bentuk KSP telah menjadi momok. Mencoba membuat sintaks dapat diakses oleh boneka, yang merupakan musisi, alih-alih menyelesaikan implementasi API dalam bahasa manusia, Nativs menulis penerjemah mereka sendiri untuk bahasa mereka sendiri, arsitektur yang awalnya tidak mengandaikan penerbangan imajinasi para pengembang alat yang penuh badai, yang kita saksikan sekarang. Sudah pada versi 3, penduduk asli kehilangan harapan untuk mengikuti selera pengguna, dan mulai memukau fungsi-fungsi baru dari perpustakaan standar, memungkinkan pengguna untuk mengetahui lingkungan pengembangan kode sendiri.

Selain itu, bahkan Nils Lieberg KScriptEditor muncul , bercabang dengan Scintilla , yang telah lama berfungsi sebagai IDE utama untuk KSP. Sungguh konyol untuk mengatakan, tetapi ketika penduduk asli menyadari bahwa kontak tersebut tidak dapat mengatasi ukuran sumber yang diumpankan, mereka memperkenalkan fungsi ke dalam bahasa, tanpa repot-repot menyampaikan argumen ke dalamnya. Dan sebulan kemudian sebuah taskfunc muncul di taskfunc , meneruskan argumen ke fungsi yang tidak menggunakan argumen.

Setelah beberapa saat, Niels menyadari bahwa ia menginjak penggaruk penduduk asli: tidak ada gunanya mengembangkan IDE sendiri. Dia porting compiler dan mengimplementasikan fungsionalitas IDE ke SublimeText2, dan melambaikan tangan. Saat ini, kendali SublimeKSP ditanggung oleh pengembang, tampaknya, dari Fluffy Audio .

Yah, kamu mengerti)

Dan lagi, sudah menjadi pembuat kode, yang tidak kurang dari bahasa, dengan sistem impor, parser, kompiler, sintaks berbeda dari KSP, tetapi masih mendukung kompatibilitas dengan itu, untuk alasan yang tidak diketahui ilmu pengetahuan, itu ternyata menjadi gunung kruk mengerikan yang tidak dapat dibuang. karena kompatibilitas mundur proyek pengembang perpustakaan yang telah mengembangkan mesin KSP mereka selama bertahun-tahun.

Misalkan sistem impor bekerja secara global berkenaan dengan file dari mana kompilasi diluncurkan, oleh karena itu, untuk mengkompilasi satu modul yang terletak di subfolder, perlu untuk sepenuhnya mengubah jalurnya dalam impor, sesuai dengan posisinya dalam struktur proyek. Dan pria yang mendukungnya akan dengan senang hati mengubah ini, tapi kemudian dia akan menghancurkan proyek-proyek dari Spitfire Audio yang sama untuk waktu yang lama. Dan fakta ini saja menyulitkan pengujian modular (jangan katakan apapun tentang unit) ke neraka.

Tampaknya solusi untuk masalah ini adalah dengan menggunakan symlink, tetapi di suatu tempat di sana tidak berfungsi seperti yang diharapkan, dan symlink hanya berfungsi sebagian. Masalah seperti ini bukan satu hal. Antara lain, setelah Niels, pengembangan tidak dilakukan dengan memodifikasi kompiler itu sendiri, yang menerima kode yang sudah diuraikan. Dan, sekali lagi, untuk alasan kompatibilitas ke belakang, dengan menambahkan plug-in dari sintaks yang diperluas, masing-masing menerima sumber yang awalnya dipotong menjadi garis-garis, mem-parsingnya sendiri, dan membuat modifikasi.

Mengingat bahwa sebagian besar logika preprosesor bersandar pada makro dan fungsi sebaris yang menyebarkan kode ke kanvas besar yang menyimpan 80% kondisi selalu benar atau selalu salah (dengan mengganti konstanta untuk input kondisi), yang runtuh kembali pada tahap parsing AST, waktu kompilasi sumber "benar" sebanding dengan Dengan proyek, ini dalam bahasa yang ditafsirkan untuk boneka.

Mengatakan bahwa KSP telah menjadi masalah bagi pengembang adalah tidak mengatakan apa-apa.

Tidak ada satu kontak pun.

Saya tidak bisa memberikan contoh dari bidang lain, tetapi di sini dari lingkup DigitalAudio:

• Lemur adalah aplikasi sekop dengan editor desktop yang memungkinkan Anda untuk dengan cepat membuat antarmuka yang indah untuk berkomunikasi sekop menggunakan protokol OSC . Ini memiliki PL sendiri, yang dapat digunakan dalam objek skrip khusus yang tersebar di seluruh pohon proyek. Tidak ada cara untuk membuat kompiler seperti apa yang dilakukan untuk KSP.
• Reaper - DAW dengan ekosistem pengembangan ekstensi yang dikembangkan. Akibatnya, jika memungkinkan, saya menggandakan kode bahasa JSFX (ReaScript) saya sebagai API untuk C ++, lua dan Python.
• HISE adalah penulis dan pembangun VST \ VSTi muda yang akan membunuh Kontakt dari pengembang Swedia Christoph Haart cepat atau lambat. Di dalam editor itu sendiri, ini memungkinkan Anda untuk menulis dalam JavaScript yang dimodifikasi, yang diuraikan dan dikompilasi ke dalam biner oleh objek C ++. Gagasan dengan parser Anda sendiri untuk memperkenalkan entitas tambahan (misalnya, mendaftarkan variabel, jika saya menerjemahkan dengan benar) bekerja hingga pengguna mentransfer kode mereka dari editor HISE ke IDE favorit mereka dengan penyorotan sintaksis, analisis statis dan alat pemformatan JsPrettier . Sekarang Christophe membuat sketsa beberapa file header untuk mengkompilasi pustaka statis di C ++, yang kemudian dapat digunakan sebagai modul dalam editor. Secara paralel, ia terus menambahkan HISEScript (karena JavaScript tidak dapat lagi menyebutnya) dengan fungsi baru, tetapi kita tahu bahwa ...

Kesimpulan

Menulis aplikasi Anda sendiri, mengabdikan diri pada fungsi utamanya, jangan buang waktu untuk parser, semantik, dan sintaksis. Ini menarik saat Anda mulai, tetapi dengan probabilitas tinggi akan mengarah ke jalan buntu. Bahasa pemrograman tidak dapat menjadi bagian dari aplikasi: ini adalah jenis jalur produksi terpisah yang membutuhkan banyak waktu untuk mempertahankan, memodifikasi, dan mendukung komunitas. Pada gilirannya, jika Anda berharap untuk menurunkan ambang batas untuk boneka, jatuhkan. Teko nyata, sebagai suatu peraturan, takut untuk mencetak apa pun, dan tidak akan mengganggu dirinya sendiri dengan sintaksis sederhana Anda.

Pada saat yang sama, untuk pengembang plug-in pemula untuk program Anda, Anda cukup membuat QuickStartGuide kecil, memperkenalkan mereka pada konsep dasar PL pilihan Anda untuk memperluas fungsionalitas dan perlahan memberinya API Anda, yang merupakan bagian dari ekosistem bahasa ini.

PS Tidak, menulis parser Anda sendiri untuk PL yang sudah jadi juga merupakan ide yang buruk.

Saya akan senang dengan kritik apa pun dari artikel ini, pancake pertama dan semua hal.