Contoh kapan kita akan menggunakan bahasa yang ditafsirkan di atas bahasa yang dikompilasi?

11

Saya memahami perbedaan antara bahasa yang ditafsirkan dan dikompilasi, tetapi jika seseorang dapat memberikan beberapa contoh situasi ketika seseorang cenderung menggunakan bahasa yang ditafsirkan di atas bahasa yang dikompilasi, serta situasi ketika seseorang cenderung menggunakan bahasa yang dikompilasi daripada bahasa yang ditafsirkan, itu akan sangat membantu.

programming-languages KL
sumber

Jawaban:

11

(Setahu saya) tidak ada yang namanya "bahasa" yang diinterpretasikan atau "bahasa" yang dikompilasi.

Bahasa menentukan sintaksis dan makna kata kunci kode, konstruk alur, dan berbagai hal lainnya, tetapi saya tidak mengetahui bahasa yang menentukan apakah harus dikompilasi atau ditafsirkan dalam spesifikasi bahasa.

Sekarang jika pertanyaan Anda adalah ketika Anda menggunakan kompiler bahasa vs juru bahasa, itu benar-benar turun ke pro / kontra dari kompiler vs interpreter dan tujuan proyek.

Sebagai contoh, Anda dapat menggunakan kompiler JRuby untuk integrasi yang lebih mudah dengan perpustakaan java daripada penerjemah ruby ​​MRI. Ada kemungkinan juga alasan untuk menggunakan juru bahasa rubi MRI di atas JRuby, saya tidak terbiasa dengan bahasa dan tidak dapat berbicara dengan ini.

Manfaat yang didapat dari penerjemah:

  • Tanpa kompilasi berarti waktu dari mengedit kode hingga menguji aplikasi dapat dikurangi
  • Tidak perlu membuat binari untuk banyak arsitektur karena juru bahasa akan mengelola abstraksi arsitektur (meskipun Anda mungkin masih perlu khawatir tentang skrip yang menangani ukuran integer dengan benar, hanya saja bukan distribusi biner)

Manfaat yang dikemukakan dari kompiler:

  • Kode asli yang dikompilasi tidak memiliki overhead juru bahasa dan karena itu biasanya lebih efisien dalam hal waktu dan ruang
  • Interoperabilitas biasanya lebih baik, satu-satunya cara untuk in-proc interoperation dengan skrip adalah melalui interpreter daripada FFI standar
  • Kemampuan untuk mendukung arsitektur yang belum dikompilasi oleh interpreter (seperti embedded system)

Namun, saya berani bertaruh dalam 90% kasus, ini berjalan seperti ini: Saya ingin menulis perangkat lunak ini di blub karena saya tahu betul dan harus melakukan pekerjaan dengan baik. Saya akan menggunakan interpreter blub (atau kompiler) karena itu adalah metode kanonik yang diterima secara umum untuk menulis perangkat lunak dalam blub.

Jadi TL; DR pada dasarnya, berdasarkan kasus per perbandingan pembanding dengan kompiler untuk kasus penggunaan khusus Anda.

Juga, FFI: Antarmuka Fungsi Asing, dengan kata lain antarmuka untuk beroperasi dengan bahasa lain. Lebih banyak membaca di wikipedia

Jimmy Hoffa
sumber
2
Sepengetahuan saya, beberapa bahasa scripting untuk OS seperti ksh untuk UNIX tidak dapat dikompilasi.
NoChance
@ Dave, maksud saya adalah tidak dapat dikompilasi melalui komersial atau perangkat lunak gratis yang saya tahu, bukan karena tidak dapat dikompilasi karena alasan teknis.
NoChance
3
@EmmadKareem Tidak ada yang namanya "tidak bisa dikompilasi". Anda menulis sebuah program yang membaca sebuah program dalam bahasa Li dan menghasilkan program yang setara dalam bahasa La. Itu adalah kompiler kompilator. Saya ragu-ragu untuk mengajukan argumen kelengkapan turing karena ini adalah herring merah dalam praktiknya, tetapi setiap program akhirnya berubah menjadi urutan instruksi kode mesin. Jika semuanya gagal, lepaskan gulungan interpreter (dan sederhanakan kode yang dihasilkan untuk menghapus bagian yang tidak Anda butuhkan lagi). Jika penerjemah ditulis dalam bahasa tanpa penerjemah, ulangi sampai Anda menemukan sesuatu dengan kompiler.
1
(Saya mengubah komentar saya menjadi lebih baik, tetapi ternyata saya bertindak terlambat.) @EmmadKareem Ya, jelas beberapa bahasa tidak pernah diimplementasikan melalui kompiler. Tetapi saya gagal melihat bagaimana ini relevan. Itu selalu mungkin dan layak untuk dilakukan, dan dapat dilakukan kapan saja dengan sedikit usaha. Ini adalah konsekuensi dari poin utama, yaitu bahwa bahasa tidak secara inheren dikompilasi atau diinterpretasikan, dan dapat diimplementasikan dengan dua cara. Dan dalam berbagai cara lain (well, bisa dibilang varian kecil dan remix), omong-omong.
2
@EmmadKareem jika Anda mau, Anda bisa mengambil spec bahasa ksh dan menulis kompiler yang membacanya dan menghasilkan biner asli. Bahasa yang dikompilasi atau ditafsirkan tidak dalam definisi bahasa adalah poin saya di sini.
Jimmy Hoffa
8

Poin penting di sini adalah bahwa banyak implementasi bahasa benar-benar melakukan semacam hibrida dari keduanya. Banyak bahasa yang umum digunakan saat ini bekerja dengan mengkompilasi program ke dalam format perantara seperti bytecode, dan kemudian mengeksekusinya dalam sebuah interpreter. Ini adalah bagaimana Java, C #, Python, Ruby, dan Lua biasanya diimplementasikan. Bahkan, ini bisa dibilang bagaimana sebagian besar bahasa yang digunakan saat ini diimplementasikan. Jadi, kenyataannya adalah, bahasa saat ini menafsirkan dan menyusun kode mereka. Beberapa bahasa ini memiliki kompiler JIT tambahan untuk mengkonversi bytecode ke kode asli untuk dieksekusi.

Menurut pendapat saya, kita harus berhenti berbicara tentang bahasa yang ditafsirkan dan dikompilasi karena mereka bukan lagi kategori yang berguna untuk membedakan kompleksitas implementasi bahasa saat ini.

Ketika Anda bertanya tentang kelebihan bahasa yang ditafsirkan dan dikompilasi, Anda mungkin bermaksud sesuatu yang lain. Anda mungkin bertanya tentang manfaat pengetikan statis / dinamis, manfaat mendistribusikan executable asli, keuntungan relatif kompilasi JIT dan AOT. Ini semua adalah masalah yang terkait dengan interpretasi / kompilasi tetapi merupakan masalah yang berbeda.

Winston Ewert
sumber
2

Pertama-tama, bahasa pemrograman dapat ditafsirkan dan dikompilasi. Interpretasi dan kompilasi hanyalah metode untuk menghasilkan kode yang dapat dieksekusi dari kode sumber. Dengan seorang juru bahasa kode sumber sedang dibaca dan ditafsirkan oleh seorang juru bahasa yang kemudian mengeksekusi kode itu ketika menafsirkannya. Seorang kompiler di sisi lain membaca kode sumber dan menghasilkan file biner yang dapat dieksekusi dari kode sumber - sehingga program dapat dijalankan sebagai proses terpisah secara independen.

Sekarang sebelum orang bertanya-tanya ... Ya, C / C ++ / C # / Java dapat diartikan, dan ya, JavaScript dan skrip Bash dapat dikompilasi. Namun, apakah ada penerjemah atau kompiler yang berfungsi untuk bahasa-bahasa ini adalah pertanyaan lain.

Sekarang untuk benar-benar menjawab pertanyaan ketika kita akan menggunakan "bahasa yang ditafsirkan" di atas "bahasa yang dikompilasi". Pertanyaan itu sendiri agak membingungkan, tetapi saya menganggap itu berarti kapan lebih suka interpretasi daripada kompilasi. Salah satu kelemahan kompilasi adalah bahwa ia menghasilkan beberapa overhead karena proses kompilasi - kode sumber harus dikompilasi ke kode mesin yang dapat dieksekusi sehingga tidak cocok untuk tugas-tugas yang memerlukan penundaan minimal ketika menggunakan kode sumber untuk menjalankan suatu program. Di sisi lain kode sumber yang dikompilasi hampir selalu lebih cepat daripada kode sumber yang ditafsirkan setara karena overhead yang disebabkan oleh menafsirkan kode. Penerjemah di sisi lain dapat memanggil dan menjalankan kode sumber dengan overhead doa yang sangat sedikit, tetapi dengan mengorbankan kinerja run-time.

Pada akhirnya hampir tidak mungkin untuk menyebutkan kasus penggunaan yang pasti kapan harus memilih satu demi satu, tetapi misalnya satu (untuk penjelasan saya sangat tidak realistis) kasus akan ketika kode sumber program berubah secara dinamis antara permintaan program dan overhead kompilasi juga tinggi untuk itu menjadi pilihan yang layak. Dalam hal itu menafsirkan kode sumber daripada mengkompilasi mungkin akan diinginkan.

Namun, ada sesuatu yang dapat dianggap sebagai contoh dunia nyata: kode sumber hidnig pada saat penyebaran. Dengan aslinyakode yang dikompilasi, pengembang menyebarkan kode macine yang dapat dieksekusi dari program dan data. Dengan kode yang diinterpretasikan, kode sumber itu sendiri harus digunakan yang kemudian dapat diperiksa dan direkayasa ulang dengan upaya yang jauh lebih sedikit daripada apa yang dilakukan untuk merekayasa balik kode mesin asli. Satu pengecualian untuk ini adalah bahasa seperti C # dan Java yang mengkompilasi ke bahasa langsung / bytecode (MSIL untuk C # dan Java bytecode untuk Java) yang kemudian dikerahkan dan dikompilasi "tepat waktu" saat runtime, seperti halnya penerjemah. Namun, ada yang disebut decompiler untuk MSIL dan Java Bytecode yang dapat merekonstruksi kode sumber asli dengan akurasi yang relatif baik dan dengan demikian rekayasa balik produk tersebut jauh lebih sepele daripada produk rekayasa balik yang digunakan dalam kode mesin asli.

zxcdw
sumber
1
Anda membuat poin yang bagus, tetapi sebagai pedant saya, saya mengambil masalah dengan beberapa ungkapan (keduanya merujuk pada paragraf ketiga): 1. Seorang juru bahasa tidak mengkompilasi. 2. Dapat dipahami (walaupun kondisi ini jarang terjadi) untuk kompiler buruk yang tidak mengoptimalkan dapat dikalahkan oleh penerjemah yang sangat dioptimalkan (terutama berdasarkan bytecode). Ini berlaku dua kali lipat jika Anda menghitung kompiler JIT di bawah juru bahasa (yang saya lebih suka tidak melakukannya, tetapi beberapa orang melakukannya).
@delnan Mungkin kata-katanya buruk, saya bukan penutur asli bahasa Inggris. Namun, sejauh yang saya tahu paragraf ketiga tidak menyiratkan bahwa penerjemah akan dikompilasi. Untuk poin kedua, saya menekankan pada kata yang setara dengan penekanan kesamaan kode dikompilasi dan ditafsirkan untuk mengecualikan kasus-kasus kompiler miskin vs penerjemah kinerja tinggi, mungkin saya tidak jelas dengan itu, namun saya tidak melihatnya masuk akal untuk fokus menjelaskan kasus-kasus ekstrem seperti itu karena tidak memberikan kontribusi apa pun pada titik yang dibuat antara perbedaan dalam mengeksekusi kode sumber dengan mengkompilasi atau mengartikannya
zxcdw
Maaf, jangan pernah pikirkan poin pertama, saya salah membaca sesuatu. MEA Culpa. Adapun poin kedua: Saya mengambil "setara" untuk merujuk ke kode yang ditafsirkan atau dikompilasi (dan membandingkan kompiler dan interpreter tidak masuk akal, karena mereka melakukan hal-hal yang berbeda secara fundamental). Saya pikir seseorang tidak perlu membuang waktu untuk merinci kasus-kasus aneh seperti contoh saya, tetapi saya lebih suka membuang kata "selalu" demi sebuah frasa yang menjelaskan mengapa hal itu bisa lebih cepat di tempat pertama: Tidak ada overhead juru bahasa [yang seharusnya mendefinisikan IMHO], dan peluang untuk melakukan optimasi sebelum runtime.
1

Saya bisa memikirkan skenario berikut ketika Anda akan menggunakan bahasa yang ditafsirkan :

  • Di mana tidak ada kompiler, seperti skrip Linux / Unix shell .
  • Skrip cepat dan kotor yang menyelesaikan sedikit masalah
  • Bahasa yang membuatnya mudah untuk menulis halaman HTML dinamis dan pada umumnya ditafsirkan seperti JSP (Tomcat mengkompilasinya menjadi servler previos untuk dijalankan), PHP, ASP dll.

Saya dapat memikirkan skenario berikut ketika Anda ingin mengkompilasi kode Anda:

  • Anda perlu mendistribusikan binari karena aplikasi Anda adalah sumber tertutup dan Anda tidak ingin membagikan kode sumber Anda.
  • Kecepatan, seperti embedded system dan sejenisnya.
  • Anda memerlukan tingkat keamanan jenis kode yang hanya dapat diberikan oleh kompiler dengan bahasa yang diketik dengan ketat. Compiler mengekspos kesalahan ketik di setiap sudut dan celah kode sumber Anda, sedangkan dalam program yang diinterpretasikan kesalahan ketik bisa tidak ditemukan ke dalam kode produksi.
  • Sistem besar dan kompleks: tidak dapat membayangkan OS atau setelan kantor sebagai apa pun selain kompilasi binari.
  • Anda ingin mendapatkan setiap overhead kecil keluar dari jalan dan membutuhkan komunikasi yang baik dengan cuplikan assembler (sulit dengan segala jenis runtime, terutama dengan penerjemah) (titik ini dibawa oleh komentar @namnam)
Tulains Córdova
sumber
3
Seorang juru bahasa membuat bahasa yang diketiknya tidak kalah kuat. Haskell diketik dengan sangat kuat dan Anda dapat menggunakan GHCI untuk menafsirkannya secara efektif. Pengetikan kuat / lemah adalah aspek bahasa, bukan aspek kompiler atau juru bahasa.
Jimmy Hoffa
1
-1 Pada pro kompilasi: (1) Kompilasi kode tidak melindungi terhadap rekayasa terbalik, itu hanya membuatnya sedikit lebih sulit. (2) Kompilasi (penghapusan overhead juru, optimasi kode aplikasi otomatis) hanya satu sumber kinerja, dan dilampaui oleh optimasi skala besar yang dilakukan sendiri oleh seorang ahli manusia. (3) Pemeriksaan tipe, meskipun biasanya digabungkan dengan kompilasi, tidak tergantung pada kompilasi. Pemeriksa tipe adalah pass analisis statis; itu bisa terjadi tanpa memancarkan kode dan sebelum menafsirkan kode. (4) Tampaknya sangat palsu. Anda "tidak bisa membayangkan" itu? Mengapa? Bagaimana ini diperlukan?
1
Bahasa yang diterjemahkan lainnya ada setiap kali ada juru bahasa di program lain. Setiap kali seseorang menggunakan pola juru bahasa , ada bahasa yang ditafsirkan dari beberapa kompleksitas.
3
"skrip" tidak harus ditafsirkan. Banyak bahasa "scripting" dikompilasi menjadi bytecode untuk mesin virtual yang kemudian dieksekusi (lihat lua, perl, python, ruby). Tidak ada perbedaan nyata antara ini dan java selain ketika kompilasi berlangsung.
3
+1, saya pikir itulah jawaban OP yang benar-benar dicari, dan meskipun poinnya mungkin tidak 100% benar seperti yang ditunjukkan, setidaknya ada 95% benar untuk pertimbangan praktis.
Doc Brown
1

Pada akhirnya, pertukaran besar adalah antara produktivitas (berapa banyak baris kode yang harus Anda tulis) dan kinerja (seberapa cepat program Anda akan dijalankan).

Karena bahasa yang ditafsirkan ketika ditransformasikan ke informasi CPU memiliki lebih banyak informasi, mereka dapat mengandalkan refleksi dan pengetikan dinamis yang sangat meningkatkan produktivitas . Keuntungan lain dari bahasa yang ditafsirkan adalah bahwa mereka adalah platform independen selama ada penerjemah untuk platform.

Karena CPU tidak boleh mengubah kode bahasa dalam kode mesin dan menjalankan kode pada saat yang sama, seperti dalam kasus yang ditafsirkan, bahasa yang dikompilasi menghasilkan program yang lebih cepat. Selain itu, sistem yang dibangun dalam bahasa yang dikompilasi lebih aman karena dapat mendeteksi masalah pada waktu kompilasi yang pada dasarnya berarti Anda melihat kesalahan saat Anda mengetiknya (dengan IDE modern) alih-alih melihatnya hanya ketika Anda benar-benar menjalankan program (tentu saja , ini tidak memperbaiki kesalahan logis).

Mengetahui hal ini, bahasa yang ditafsirkan cocok untuk:

  1. Pengembangan produktif: pengembangan web cepat (PHP, Javascript) atau untuk pembuatan prototipe.
  2. Cross-Platform; misalnya JavaScript didukung di setiap browser (termasuk browser seluler).

Dan bahasa yang dikompilasi cocok ketika:

  1. Kinerja sangat penting (sistem operasi) atau sumber daya langka (mikrokontroler).
  2. Sistem yang akan dibangun sangat kompleks; ketika membangun sistem besar (sistem perusahaan) bahasa yang dikompilasi sangat penting menangani banyak bug yang mungkin muncul dalam bahasa yang ditafsirkan; juga program yang kompleks membutuhkan banyak sumber daya dan keseimbangan cenderung untuk mengkompilasi bahasa juga.
m3th0dman
sumber
-1 karena Anda menyiratkan bahwa semua bahasa yang ditafsirkan diketik secara dinamis dan semua bahasa yang dikompilasi diketik secara statis, yang sama sekali tidak benar.
Daniel Pryden
@DanielPryden Pasti itu kebetulan murni, fakta bahwa hampir semua bahasa yang ditafsirkan diketik secara dinamis dan yang dikompilasi diketik secara statis? Apakah ini suatu kebetulan bahwa model tipe dinamis cocok untuk bahasa yang ditafsirkan?
m3th0dman
Karena berbagai alasan, ada korelasi, tetapi itu bukan keharusan. Ini sebenarnya telah ditanyakan pada StackOverflow: Mengapa sebagian besar penterjemahan sebagian besar ducktyped sementara dikompilasi memiliki pengetikan yang kuat?
Daniel Pryden
1
Erlang dikompilasi dan diketik secara dinamis. Haskell diketik secara statis dan dapat dikompilasi atau diinterpretasikan
Zachary K
1
@ZacharyK Erlang memiliki sistem run-time; Haskell dikompilasi dalam sebagian besar kasus (program ditulis).
m3th0dman
1

Selain alasan yang disebutkan orang lain, ada satu kasus penggunaan yang sangat penting untuk memilih interpretasi ad hoc atas segala bentuk kompilasi atau pendekatan hybrid.

Dalam hal jika bahasa pemrograman digunakan sebagai protokol komunikasi , dan ketika latensi respons penting, lebih masuk akal untuk menghindari membuang-buang waktu untuk kompilasi dan kemungkinan preprocessing.

Ini berlaku untuk bahasa agen, misalnya, atau untuk cara bagaimana, katakanlah, Tcl / Tk biasanya digunakan.

Alasan lain yang mungkin untuk tetap dengan interpretasi adalah ketika juru bahasa digunakan untuk bootstrap itu sendiri atau bahasa tingkat yang lebih rumit, lebih tinggi, dan kesederhanaannya lebih penting daripada kinerja proses bootstrap.

Untuk hampir semua kasus penggunaan lain yang mungkin, kompilasi (atau pendekatan hybrid) lebih cocok.

Logika SK
sumber