Saya seorang mahasiswa pascasarjana baru-baru ini bertujuan untuk memulai Master saya di bidang Ilmu Komputer. Saya telah menemukan banyak proyek open source yang benar-benar menggelitik saya dan mendorong saya untuk berkontribusi pada mereka (CloudStack, OpenStack, moby, dan Kubernets untuk beberapa nama). Satu hal yang saya temukan bahwa mayoritas dari mereka memiliki kesamaan adalah penggunaan beberapa bahasa pemrograman (seperti Java + Python + Go atau Python + C ++ + Ruby). Saya sudah melihat pertanyaan lain ini, yang berkaitan dengan bagaimana beberapa bahasa pemrograman dibuat untuk berkomunikasi satu sama lain: Bagaimana caranya agar dua program berbeda dengan dua bahasa berbeda berinteraksi?
Saya ingin memahami persyaratan yang mendorong perusahaan untuk menggunakan beberapa bahasa pemrograman. Apa persyaratan atau jenis persyaratan yang membuat arsitek perangkat lunak atau pimpinan proyek mengatakan, "Saya mengusulkan agar kita menggunakan bahasa X untuk tugas 1 dan bahasa Y untuk tugas 2"? Sepertinya saya tidak mengerti alasan mengapa banyak bahasa pemrograman digunakan dalam produk atau perangkat lunak yang sama.
sumber
Jawaban:
Jawaban ini memiliki jangkauan dan tautan luar biasa tentang mengapa berbagai bahasa dapat memberikan manfaat yang berbeda untuk suatu proyek. Namun, ada sedikit lebih dari sekadar kesesuaian bahasa yang terlibat dalam mengapa proyek akhirnya menggunakan banyak bahasa.
Proyek akhirnya menggunakan banyak bahasa karena enam alasan utama:
Alasan 1-4 adalah alasan positif dalam arti bahwa mengatasinya secara langsung dapat membantu proyek menyimpulkan lebih cepat, lebih efisien, dengan produk berkualitas lebih tinggi, dan dengan dukungan jangka panjang yang lebih mudah. Alasan 5 dan 6 adalah negatif, gejala penolakan terhadap perubahan yang diperlukan, perencanaan yang buruk, manajemen yang tidak efektif, atau kombinasi dari semua faktor ini. Sayangnya, faktor-faktor negatif ini merupakan penyebab umum dari penggunaan multi-bahasa yang "tidak disengaja".
Alasan 1 , manfaat biaya penggunaan kembali, telah menjadi alasan yang semakin kuat untuk memungkinkan penggunaan berbagai bahasa dalam suatu proyek karena peran perangkat lunak open source yang lebih besar dan kemampuan yang ditingkatkan untuk menemukan komponen kode yang tepat di web. Filsafat "mari kode semuanya internal" dari dekade terakhir terus memudar dalam menghadapi realitas ekonomi, dan pada dasarnya tidak pernah pendekatan yang paling hemat biaya untuk setiap proyek baru. Hal ini pada gilirannya membuat peluang untuk penegakan yang ketat terhadap penggunaan satu bahasa dalam proyek menjadi kurang umum.
Terutama dalam kasus proyek menggunakan kembali komponen open source yang dikelola dengan baik, penggunaan berbagai bahasa dapat memberikan manfaat biaya keseluruhan yang besar karena komponen yang digunakan kembali keduanya tersembunyi di balik antarmuka yang dirancang dengan baik, dan dikelola secara independen oleh kelompok eksternal tanpa biaya. Dalam skenario terbaik, pencampuran bahasa melalui penggunaan kembali semacam ini tidak lebih mahal untuk proyek daripada menggunakan komponen sistem operasi. Saya tahu tidak ada contoh yang lebih baik dari nilai pendekatan ini selain adopsi besar-besaran Microsoft dari perangkat lunak open source di browser mereka.
Alasan 2 , kebutuhan untuk mengakomodasi kode warisan, diabaikan pada bahaya proyek besar apa pun. Namun banyak masalah kode warisan dapat menyebabkan, secara naif berasumsi bahwa itu dapat diganti dengan mudah dengan kode baru dalam bahasa baru bisa sangat berisiko. Kode warisan, bahkan kode warisan yang buruk, sering kali mencakup jumlah "kontrak" implisit fitur yang diharapkan oleh komunitas yang menggunakan produk lawas. Komunitas itu cukup sering merupakan sumber pendapatan utama bagi sebuah perusahaan, atau target utama dukungan untuk perangkat lunak pemerintah. Membuang kontrak yang tersirat dapat mengejar pelanggan yang sadar berbondong-bondong, dan dapat membuat perusahaan bangkrut dalam semalam jika opsi lain tersedia.
Pada saat yang sama, tidak mengganti kode lama dalam bahasa lama bisa sama berbahayanya dengan mengganti secara grosir. Contoh kasus terburuk adalah Administrasi Veteran AS, yang memiliki sejumlah besar sistem vital yang dikodekan dalam bahasa yang disebut MUMPS (tidak bercanda) yang dirancang oleh dokter medis, bukan ilmuwan komputer. Tidak ada yang mau belajar MUMPS, dan mereka yang tahu benar-benar sekarat. Programer karena itu harus mengakomodasi MUMPS bahkan ketika mereka mencoba untuk bergerak maju menggunakan bahasa lain yang lebih umum, lebih kuat, dan lebih terpelihara.
Jenis penggunaan multi-bahasa ini membutuhkan perencanaan yang cermat. Perencanaan itu harus menavigasi ujung pisau antara kehilangan puluhan tahun pengetahuan pelanggan di satu sisi, dan kehilangan kemampuan untuk mendukung perangkat lunak di sisi lain. Teknik yang mengisolasi kode lama di belakang antarmuka yang terdefinisi dengan baik, dan yang memungkinkan kode baru yang lebih kuat untuk menggantikan kode lama setelah perilakunya didokumentasikan dengan baik, dapat membantu. Tetapi skenario warisan ini tidak pernah mudah, dan telah (dan akan terus menjadi) penyebab kematian banyak perusahaan dan organisasi di berbagai spektrum ukuran.
Alasan 3 , ketersediaan coder untuk berbagai bahasa, adalah faktor pragmatis yang diabaikan proyek. Betapapun penyelenggara proyek mungkin merasa (benar atau salah) bahwa bahasa tertentu adalah yang terbaik untuk tujuan mereka, jika bahasa tersebut bertentangan dengan kumpulan keahlian bahasa yang tersedia untuk mereka, baik jadwal dan kualitas produk akan menderita dari pembelajaran melengkung programmer mencoba belajar bahasa baru.
Pendekatan yang lebih rasional adalah menganalisis kebutuhan bahasa proyek berdasarkan area fungsional. Sebagai contoh, melihat dengan seksama pada proyek dapat menunjukkan bahwa hanya ada "puncak" kecil dari kode bernilai tinggi, misalnya untuk mengimplementasikan beberapa algoritma kepemilikan, yang membutuhkan keahlian pengkodean dalam bahasa yang kurang umum digunakan. Bagian lain dari setiap proyek besar seringkali mudah ditampung oleh bahasa yang lebih umum, atau (bahkan lebih baik) oleh produk open source yang dikelola dengan baik. Menganalisis proyek berdasarkan kebutuhan bahasa dapat memberikan pendekatan yang jauh lebih realistis dan hemat biaya untuk mempekerjakan atau menyewa keahlian khusus dalam bahasa khusus, dan juga dapat membantu mempertajam antarmuka antar bahasa dalam satu proyek tunggal.
Alasan 4 , menggunakan bahasa yang berbeda untuk kebutuhan yang berbeda, mengikuti segera dan dengan lancar melakukan analisis kebutuhan proyek semacam itu. Perhatian harus digunakan dalam hal ini juga, karena memilih terlalu banyak bahasa untuk dukungan dalam satu proyek tunggal dapat menyebabkan ledakan kombinasi kompleksitas baik dalam dukungan dan antarmuka antara komponen. Rute teraman dari segi biaya adalah untuk selalu menemukan peluang maksimum untuk digunakan kembali terlebih dahulu, terutama jika ada paket bagus yang dapat memenuhi kebutuhan proyek melalui sedikit lebih dari penyesuaian. Selanjutnya, beberapa jenis keputusan harus dibuat pada sejumlah kecil bahasa yang dapat menjawab sebagian besar kebutuhan yang diidentifikasi. Dalam pengembangan intensif-penggunaan ulang, ini akan sering menjadi jenis kode lem.
Pada umumnya bukan ide yang baik untuk memilih beberapa bahasa dengan kemampuan yang sangat mirip hanya karena beberapa anggota proyek menyukai satu dan beberapa yang lain. Namun, jika ada subset kemampuan yang diidentifikasi dengan baik dan terdefinisi dengan baik yang akan mendapat manfaat dari keterampilan bahasa khusus, itu bisa menjadi alasan yang baik untuk menggunakan beberapa bahasa untuk pengembangan kode baru.
Alasan 5 , penolakan terhadap perubahan yang diperlukan dalam bahasa yang digunakan, dapat menjadi penyebab gangguan proyek yang parah dan perselisihan internal. Sebagai pengguna Daveoditunjukkan dalam komentar pada jawaban ini, perubahan bisa sangat sulit bagi beberapa personel proyek. Pada saat yang sama, penolakan terhadap perubahan tidak pernah menjadi masalah sederhana, dan itulah sebabnya hal itu dapat menyebabkan banyak perselisihan. Penggunaan keterampilan bahasa lawas dapat menjadi pendorong kuat bagi produktivitas suatu proyek jika bahasa lawas cukup kuat, dan dapat mengarah pada produk dengan kualitas luar biasa dalam tim yang beroperasi dengan lancar dan menghargai kualitas. Namun, keterampilan bahasa lawas harus diimbangi dengan fakta bahwa banyak bahasa yang lebih tua tidak dapat lagi lengkap dengan bahasa yang lebih baru dalam hal fitur canggih, ketersediaan komponen, opsi sumber terbuka, dan dukungan kit alat cerdas.
Baik dulu maupun sekarang, satu-satunya argumen yang paling umum (dan ironisnya, paling sering benar) untuk terus menggunakan bahasa warisan yang lebih lemah, kurang mudah dibaca, atau kurang produktif adalah bahwa bahasa yang lebih tua memungkinkan produksi kode yang lebih efisien. Ini adalah argumen lama, argumen yang kembali ke tahun 1950-an ketika pengguna bahasa assembly membenci, seringkali dengan pahit, kemunculan pemrograman di FORTRAN dan LISP. Sebuah contoh di mana bahkan sekarang argumen efisiensi kode dapat memiliki validitas dapat dilihat dalam kode intensif pemrosesan seperti kernel sistem operasi, di mana C tetap menjadi bahasa pilihan atas C ++ (meskipun untuk alasan yang melampaui efisiensi sederhana).
Namun, dalam lingkungan proyek yang didukung secara global dan didukung mesin pada milenium baru, efisiensi kode sebagai argumen utama untuk memilih bahasa proyek semakin lemah. Ledakan yang sama dari komputasi dan perangkat keras jaringan yang telah memungkinkan pemasaran massal aplikasi kecerdasan buatan juga berarti bahwa biaya pemrograman manusia dapat dengan mudah mengerdilkan mereka yang melakukan eksekusi kode relativitas yang tidak efisien pada perangkat keras dan cloudware yang sangat murah. Ketika itu dikombinasikan dengan ketersediaan yang lebih besar untuk dalam bahasa yang lebih baru perpustakaan komponen, opsi sumber terbuka, dan kit alat canggih, jumlah kasus di mana menjaga bahasa untuk alasan efisiensi saja menjadi sangat sempit. Bahkan dalam kasus di mana itu berlaku,
Alasan yang lebih meyakinkan untuk proyek untuk tetap menggunakan bahasa warisan terjadi ketika untuk alasan apa pun proyek memiliki sedikit atau tidak ada pilihan untuk mengubah stafnya. Ini bisa terjadi misalnya ketika lini produk lawas utama dikodekan sepenuhnya dalam bahasa yang hanya fasih staf yang ada. Dalam kasus-kasus seperti itu, proyek harus melanjutkan jalur mencoba program dalam bahasa lama, atau mencoba untuk melatih staf yang ada dalam cara menggunakan bahasa baru.
Melatih staf bahasa lama dalam bahasa baru bisa menjadi bahaya dengan sendirinya. Saya masih ingat kasus di mana seorang anggota proyek yang baru saja dilatih dan beralih dari C ke C ++ mengeluh kepada saya dengan segala ketulusan bahwa ia tidak mengerti kelebihan metode berorientasi objek. Ketika saya melihat kodenya, dia telah mengubah fungsi 103 C sebelumnya menjadi 103 metode untuk satu kelas objek C ++ ... dan memang seharusnya tidak melihat bagaimana hal itu membantu apa pun.
Pesan yang lebih dalam adalah bahwa ketika orang telah memprogram dalam satu bahasa dan gaya bahasa selama bertahun-tahun atau puluhan tahun, kesulitan untuk membuat mereka "berpikir" dengan cara-cara baru bisa menjadi hampir tidak dapat diatasi, bahkan dengan program pelatihan yang baik. Dalam beberapa kasus mungkin tidak ada pilihan lain selain membawa desainer muda dan programmer yang lebih selaras dengan tren dan metode saat ini.
Alasan 6 , manajemen proyek yang buruk, berbicara untuk dirinya sendiri. Pemilihan dan penggunaan bahasa dalam suatu proyek harus selalu dipertimbangkan dan dinilai secara eksplisit, dan tidak diperbolehkan terjadi hanya secara kebetulan. Paling tidak, pemilihan bahasa dapat membuat perbedaan besar dalam nasib jangka panjang dan biaya dukungan proyek, dan karenanya harus selalu diperhitungkan dan direncanakan. Jangan menjadi MUMPS!
sumber
Ini cukup sederhana: tidak ada bahasa pemrograman tunggal yang cocok untuk semua kebutuhan dan tujuan.
Baca buku Michael L. Scott Programming Language Pragmatics
Beberapa bahasa pemrograman mendukung ekspresif dan deklaratif (banyak bahasa scripting, tetapi juga bahasa pemrograman tingkat tinggi seperti Agda , Prolog , Lisp , Haskell, Ocaml, ...). Ketika biaya pengembangan penting (waktu manusia dan biaya pengembang), sangat cocok untuk menggunakannya (bahkan jika kinerja runtime tidak optimal).
Bahasa pemrograman lain mendukung kinerja run-time (banyak bahasa tingkat rendah, dengan implementasi yang biasanya dikompilasi, seperti C ++, Rust, Go, C, assembler, juga bahasa khusus seperti OpenCL ...); seringkali spesifikasi mereka memungkinkan beberapa perilaku yang tidak terdefinisi . Ketika kinerja kode penting, lebih baik menggunakan bahasa-bahasa ini.
Beberapa perpustakaan eksternal ditulis dalam dan untuk bahasa tertentu dan ABI dan memanggil konvensi . Anda mungkin perlu menggunakan bahasa lain itu, dan mengikuti konvensi antarmuka fungsi asing , mungkin dengan menulis beberapa kode lem .
Dalam praktiknya, tidak mungkin memiliki bahasa pemrograman yang sangat ekspresif (sehingga meningkatkan produktivitas pengembang, dengan asumsi tim pengembang yang cukup terampil) dan sangat performan saat runtime. Dalam praktiknya, ada trade-off antara ekspresivitas dan kinerja.
Catatan: bagaimanapun, ada beberapa kemajuan lambat dalam bahasa pemrograman: Rust lebih ekspresif daripada C atau bahkan C ++ tetapi implementasinya hampir sama performannya, dan mungkin akan meningkat untuk menghasilkan executable yang sama cepatnya. Jadi, Anda perlu belajar bahasa pemrograman baru selama kehidupan profesional Anda; namun tidak ada Peluru Perak
Perhatikan bahwa biaya pengembangan semakin signifikan saat ini (yang tidak terjadi pada tahun 1970-an - pada waktu itu komputer di mana sangat mahal- atau dalam beberapa aplikasi yang disematkan - dengan volume produk yang besar). Aturan praktis (sangat perkiraan) adalah bahwa pengembang yang terampil mampu menulis sekitar 25 ribu baris kode sumber (didebug & didokumentasikan) setiap tahun, dan itu tidak banyak bergantung pada bahasa pemrograman yang digunakan.
Pendekatan umum adalah untuk menanamkan beberapa bahasa scripting (atau bahasa tertentu domain ) dalam aplikasi besar. Ide desain ini (terkait dengan bahasa domain-spesifik) telah digunakan selama beberapa dekade (contoh yang baik adalah editor kode sumber Emacs , menggunakan Elisp untuk skrip sejak 1980-an). Kemudian Anda akan menggunakan juru bahasa yang mudah disematkan (seperti Guile , Lua , Python, ...) di dalam aplikasi yang lebih besar. Keputusan untuk menanamkan seorang juru bahasa ke dalam aplikasi besar harus dilakukan sangat awal, dan memiliki implikasi arsitektur yang kuat. Anda kemudian akan menggunakan dua bahasa: untuk hal-hal tingkat rendah yang harus berjalan cepat, beberapa bahasa tingkat rendah seperti C atau C ++; untuk skrip tingkat tinggi, DSL atau bahasa skrip lain.
Perhatikan juga bahwa perangkat lunak yang diberikan dapat berjalan, dalam sebagian besar sistem operasi saat ini (termasuk Linux, Windows, Android, MacOSX, Hurd, ...), dalam beberapa proses kerja sama menggunakan beberapa jenis teknik komunikasi antar-proses . Ia bahkan dapat berjalan di beberapa komputer (atau banyak di antaranya), menggunakan teknik komputasi terdistribusi (mis. Komputasi awan , HPC, server klien, aplikasi web , dll ...). Dalam kedua kasus, mudah untuk menggunakan beberapa bahasa pemrograman (misalnya, kode setiap program yang berjalan pada satu proses atau komputer dalam bahasa pemrogramannya sendiri). Baca Sistem Operasi: Tiga Potong Mudah untuk lebih. Juga, fungsi asing antarmuka(mis. JNI ), ABI , konvensi panggilan , dll ... memfasilitasi pencampuran beberapa bahasa dalam program yang sama (atau dapat dieksekusi ) - dan Anda akan menemukan pembuat kode seperti SWIG untuk membantu.
Dalam beberapa kasus, Anda harus mencampur beberapa bahasa pemrograman: aplikasi web memerlukan Javascript atau Webassembly (satu-satunya bahasa yang berjalan di sebagian besar browser web) untuk bagian yang berjalan di browser (ada kerangka kerja yang menghasilkan ini, misalnya ocsigen ). Kode kernel memerlukan beberapa hal (mis. Penjadwal, atau penanganan interupsi tingkat rendah) sebagian ditulis dalam assembler, karena C atau C ++ tidak dapat mengungkapkan apa yang diperlukan di sana, pertanyaan RDBMS harus menggunakan SQL, kernel komputer perlu GPGPU yang dikodekan dalam OpenCL atau CUDA dikelola oleh kode host C atau C ++, dll. Beberapa bahasa dirancang untuk memfasilitasi campuran semacam itu (misalnya pernyataan dalam C,
asmpotongan kode di GCC MELT saya terlambat , dll ...).Dalam beberapa kasus, Anda menggunakan teknik metaprogramming : beberapa bagian proyek perangkat lunak besar Anda akan memiliki kode (misalnya dalam C atau C ++) yang dihasilkan oleh alat lain (mungkin proyek alat khusus) dari beberapa formalisasi ad-hoc: generator parser (tidak tepat disebut compiler- compiler) seperti bison atau ANTLR datang ke pikiran, tetapi juga menenggak atau RPCGEN. Dan perhatikan bahwa GCC memiliki lebih dari selusin generator kode C ++ khusus (satu untuk setiap DSL internal di dalam GCC) di dalamnya. Lihat juga contoh ini . Perhatikan bahwa metabug sulit ditemukan. Baca juga tentang kompiler bootstrap , dan tentang homoiconicity dan refleksi(ada baiknya mempelajari Lisp , bermain dengan SBCL , dan membaca SICP ; lihat juga ke pustaka kompilasi JIT seperti GCCJIT ; dalam beberapa program besar Anda dapat menghasilkan beberapa kode saat runtime menggunakannya, perhatikan aturan kesepuluh Greenspun ). Lihatlah juga pembicaraan Circuit Less Traveled di FOSDEM2018.
Terkadang, Anda ingin memberikan anotasi formal pada kode Anda (mis. Untuk membantu prover, analisa statis, kompiler), menggunakan beberapa bahasa penjelasan khusus (yang mungkin dipandang sebagai beberapa DSL). Lihatlah ACSL dengan Frama-C untuk membubuhi keterangan program C (yang kritis terhadap keselamatan), atau pragma OpenMP untuk HPC. Peringatan: menulis anotasi semacam itu dapat membutuhkan banyak keterampilan dan waktu pengembangan.
BTW, ini menunjukkan bahwa beberapa keterampilan tentang kompiler dan juru bahasa berguna untuk setiap pengembang (bahkan tanpa bekerja di dalam kompiler). Jadi bacalah Buku Naga bahkan jika Anda tidak mengerjakan kompiler. Jika Anda membuat kode penerjemah sendiri (atau jika Anda mendesain DSL), baca juga Lisp In Small Piece .
Lihat juga ini & itu & itu & bahwa jawaban saya terkait dengan pertanyaan Anda.
Pelajari juga kode sumber beberapa proyek perangkat lunak gratis besar (di github atau dari distribusi Linux Anda ) untuk mendapatkan inspirasi dan pencerahan.
Juga, beberapa bahasa pemrograman berkembang dengan menambahkan anotasi (sebagai pragma atau komentar ) ke bahasa yang ada. Untuk contoh, pikirkan ACSL (komentar-ekstensi untuk membubuhi keterangan program C untuk mengaktifkan bukti mereka dengan Frama-C ) atau OpenCL (C dialek program GPGPUs) atau OpenMP atau OpenACC
#pragmas atau umum anotasi tipe Lisp .PS: ada juga alasan sosial atau organisasi atau historis untuk mencampur bahasa pemrograman; Saya mengabaikan mereka di sini, tetapi saya tahu dalam prakteknya alasan seperti itu dominan. Baca juga The Mythical Man Month
sumber
awk(yang merupakan bahasa pemrograman lain) yang digunakan dalam skrip bash, hanya karena ia lebih sesuai untuk tugas tersebut. @titik amon masih berdiri.<sup>tetapi dengan penyesalanBanyak proyek tidak dibangun dengan banyak bahasa pemrograman. Namun, adalah umum untuk menggunakan skrip dalam bahasa lain untuk membantu dengan perangkat lunak.
Beberapa proyek memang menggunakan beberapa bahasa dalam aplikasi, misalnya inti dalam bahasa tingkat rendah yang dapat mengintegrasikan plugin dalam bahasa scripting. Dalam beberapa ekosistem (misalnya JVM atau .NET) bahasa yang tepat digunakan tidak terlalu penting karena beberapa bahasa pada runtime bahasa yang sama memiliki interoperabilitas yang baik. Sebagai contoh, saya bisa menulis proyek di Scala yang menggunakan perpustakaan Java yang ada, dan mengintegrasikan fungsi scripting dengan Groovy.
Jika suatu proyek terdiri dari beberapa alat, itu juga dapat dikembangkan dalam berbagai bahasa. Sementara konsistensi akan baik, terutama untuk proyek-proyek open source, upaya pengembangan yang tersedia dapat menjadi hambatan. Jika seseorang bersedia mengembangkan alat yang bermanfaat tetapi tidak terbiasa dengan bahasa utama, mungkin alat itu lebih berharga daripada konsistensi.
sumber
Ini memiliki dua bentuk, dan banyak organisasi yang berada di antara keduanya:
Bentuk buruk - organisasi itu berantakan, dan tidak ada yang memastikan bahwa ada satu visi teknologi untuk upaya ini. Devs kemungkinan besar menggunakan bahasa apa pun yang paling nyaman bagi mereka, atau baru-baru ini bereksperimen dengan kerangka kerja atau bahasa baru dan memutuskan untuk mulai menggunakan itu karena optimisme naif.
Bentuk yang baik - organisasi memiliki arsitektur bersih yang benar-benar bagus, cocok untuk pemrograman polyglot; memisahkan aplikasi ke dalam komponen independen dengan konteks batas yang terdefinisi dengan baik, dan kombinasi ini memungkinkan mereka untuk memilih bahasa pemrograman yang paling sederhana memungkinkan mereka untuk menulis komponen tertentu.
Realitas - biasanya lebih dari yang pertama. Saya telah melihat beberapa perusahaan memilih satu bahasa untuk domain bisnis mereka dan yang lain untuk server web mereka, dan seringkali ketiga untuk administrasi basis data mereka, yang secara teknis baik-baik saja tetapi segera kurangnya pemahaman teknis mereka (atau penolakan untuk mendengarkan staf mereka) berarti bahwa mereka berakhir dengan ketiganya kabur bersama dalam kekacauan besar, dan sering memperkenalkan lebih banyak bahasa yang sesuai untuk menyelesaikan bagian-bagian tertentu dari kekacauan.
sumber
Saya dapat berkontribusi contoh, dari proyek pemrograman yang telah berjalan selama 32 tahun, dan tampaknya masih memiliki banyak kehidupan yang tersisa di dalamnya. Ini komersial daripada open-source.
Inti ditulis dalam bahasa khusus domain, dibuat khusus untuk proyek. Ini telah terbukti sangat berguna, terutama karena mengintegrasikan rollback ke arsitektur dasar, tetapi mengkompilasi ke dalam kode C, yang kemudian kita kompilasi dengan kompiler platform. Ini telah mendukung sekitar dua puluh platform selama waktu itu, tidak termasuk variasi 32-vs 64-bit, dan saat ini dikirimkan pada enam dari mereka.
Ini memiliki add-on, yang ditulis dalam C ++, yang dimulai ketika kepala masa lalu proyek menjadi yakin bahwa C ++ / MFC / Windows / x86 akan menggantikan semua arsitektur dan platform lain, sehingga perlu menawarkan pekerjaan C ++ ke dapat mempekerjakan staf. Segala sesuatunya tidak berjalan seperti yang diharapkannya.
Selain bahasa domain dan C ++, pengembang bekerja di LISP, yang digunakan untuk menulis kasus uji, menggunakan penerjemah yang tertanam dalam harness tes. Kami mempertimbangkan untuk mengganti LISP dengan Java pada satu titik, tetapi ternyata beruntung bahwa kami tidak melakukannya.
Ini juga memiliki pembungkus untuk API utamanya, ditulis dalam C #. Ini dilakukan ketika pelanggan menuntutnya, sehingga mereka dapat menulis ulang aplikasi mereka dalam C #. Itu dibuat oleh skrip Perl, yang membaca file header C untuk API, ditambah file konfigurasi yang signifikan, dan menulis kode C # untuk pembungkus. Melakukan semua pemrosesan teks di Perl itu lebih mudah daripada melakukannya di C ++.
Ini memiliki sistem membangun sendiri, dan membutuhkannya, karena bahasa domain tidak setuju untuk membuat sistem membangun berbasis. Yang untuk platform seperti UNIX ditulis dalam skrip shell, Perl dan beberapa program kecil dalam bahasa domain. Satu untuk platform Windows ditulis dalam bahasa batch, Perl, dan program kecil yang sama dalam bahasa domain. Sistem build VMS lama ditulis dalam DCL, tetapi itu belum digunakan selama lebih dari satu dekade.
Ada beberapa pemrograman YACC / Bison di kompiler untuk bahasa domain. Ada beberapa kode pengujian untuk platform Apple yang ditulis dalam Objective-C ++. Beberapa situs web internal tim (digunakan untuk manajemen proyek, bukan bagian dari hasil kerja) ditulis dalam ASP, dan yang lainnya sebagai skrip CGI di Perl.
Pada dasarnya, ini dimulai sebagai proyek untuk mengatasi masalah yang sulit, jadi layak membuat alat khusus, yang tampaknya masih lebih cocok untuk pekerjaan ini daripada apa pun yang tersedia. Tim menganggap pemrograman sebagai keterampilan yang agak independen dari bahasa yang digunakan, jadi mereka bersedia menggunakan bahasa baru jika itu akan membuat tugas lebih mudah. Namun, fashion tidak menjadi prioritas utama mereka, sehingga mereka tidak akan membagi tugas dengan memperkenalkan bahasa baru secara gratis.
Fungsi kode ini adalah pemodelan matematika, yang digunakan pada workstation dan server (saya dapat berbicara sedikit lebih bebas jika saya tidak mengidentifikasi produk). Saat ini sekitar 25 juta LoC, dengan ukuran tim total sekitar lima puluh.
sumber
Dalam beberapa kasus, ada alat yang perlu Anda gunakan (seperti perangkat UI OS) yang paling mudah diakses dari bahasa tertentu. Misalnya pada iOS dan macOS, jika Anda ingin menulis aplikasi GUI menggunakan UIKit dan AppKit, menulis dalam Swift atau Objective-C adalah cara tercepat dan termudah untuk melakukannya. (Mungkin ada binding untuk bahasa lain, tetapi mereka mungkin di belakang rilis OS terbaru yang sedang Anda lawan, jadi mungkin tidak menawarkan semua fitur.)
Begitu sering yang terjadi adalah ketika aplikasi lintas platform, logika inti aplikasi ditulis dalam beberapa bahasa yang dapat diakses oleh keduanya, dan potongan khusus UI / OS ditulis dalam bahasa apa pun yang mereka gunakan secara asli.
Jadi jika Anda menulis aplikasi Windows dan macOS, Anda bisa menulis logika inti dalam C ++ dan menggunakan C # untuk UI pada Windows dan Swift untuk UI pada macOS. Ini menghemat waktu karena Anda tidak perlu menulis logika inti dua kali dan berurusan dengan set bug yang berbeda di kedua aplikasi, dll. Tetapi itu juga memungkinkan UI asli yang sebenarnya yang tidak memenuhi penyebut umum terendah antara platform seperti menggunakan perpustakaan UI lintas-platform akan.
sumber
Selain fakta bahwa beberapa bahasa pemrograman dapat lebih cocok untuk beberapa tugas tertentu, ada kenyataan praktis.
Dalam kenyataan praktis, ada 2 poin penting yang perlu dipertimbangkan:
Dan tentu saja sering ada bagian spesifik dari aplikasi yang memiliki kebutuhan yang sepenuhnya berbeda, seperti:
Dan di atas itu ada beberapa alat yang digunakan oleh basis kode yang canggih, banyak yang memungkinkan penyesuaian dan plugin yang diperlukan dengan bahasa lain.
sumber
Selain poin-poin lain yang benar yang telah dibuat:
Dari pengalaman, banyak keputusan bahasa atau lingkungan dibuat dengan 'jika Anda memiliki palu, semuanya terlihat seperti paku', artinya, orang cenderung menggunakan alat yang mereka kenal.
Selain itu, memperkenalkan lingkungan baru atau bahkan bahasa adalah investasi besar dalam lisensi, pelatihan, mungkin perangkat keras, dan disertai dengan kerugian besar waktu produktif - pengadaan, pasang, konfigurasi, latih setiap minggu di perusahaan yang lebih besar, dan Anda pada dasarnya mengakhiri dengan sekelompok pengembang pemula.
Pada dasarnya tidak pernah ada waktu untuk 'berinvestasi' dalam lingkungan atau bahasa yang lebih modern atau lebih baik, sehingga mereka tetap dengan apa yang mereka miliki sampai itu tidak bisa lagi berfungsi.
Khusus untuk pertanyaan Anda, jika banyak orang / tim berpartisipasi dalam pengembangan solusi, masing-masing kelompok cenderung berpegang teguh pada apa yang mereka tahu terbaik, sehingga solusi keseluruhan berpotensi memiliki banyak bahasa di dalamnya, dan pengembangan di berbagai lingkungan.
sumber
Pertanyaan ini (dan beberapa jawaban) tampaknya menganggap aplikasi adalah blok kode monolitik - ini belum tentu demikian.
Situs web khas Anda seperti Stack Exchange sebenarnya adalah sekelompok layanan berbeda yang semuanya berjalan secara independen satu sama lain, dengan semacam perpesanan di antara mereka. Layanan ini dapat (dan biasanya) diimplementasikan dalam bahasa yang berbeda, masing-masing dengan kekuatannya sendiri.
Saya bekerja pada sepotong kecil platform perbankan online, yang ditargetkan untuk bank komunitas kecil dan serikat kredit. Platform ini memiliki banyak komponen - ujung depan Web, lapisan basis data, lapisan komunikasi pihak ketiga, dll. Ini semua adalah aplikasi independen yang berjalan pada server yang berbeda dengan sistem operasi yang berbeda. Anda memiliki Javascript yang berjalan di sisi klien di browser, Anda memiliki Perl membangun halaman di sisi server, Anda memiliki beberapa layanan yang ditulis dalam C ++ yang bertindak sebagai lapisan abstraksi antara kode Perl dan prosesor inti bank, satu set aplikasi C ++ lainnya yang merutekan pesan antara berbagai lapisan, segelintir aplikasi C ++ dan skrip Perl untuk memantau kesehatan berbagai proses dan melaporkan statusnya ke monitor internal, dll., dll., dll.
Aplikasi monolitik memang masih ada, tetapi bahkan mereka dapat memanfaatkan berbagai bahasa untuk alasan yang berbeda. Anda dapat menulis 90% aplikasi di Java, tetapi gunakan JNI untuk meningkatkan C atau C ++ untuk bagian yang lebih kritis terhadap kinerja.
sumber
Saya ingin menunjukkan contoh yang sangat spesifik dari motif 'bahasa yang berbeda memiliki kekuatan yang berbeda': FORTRAN.
Fortran awalnya dikembangkan untuk memudahkan para insinyur untuk melakukan pekerjaan analisis numerik, dan banyak upaya telah dilakukan untuk membuat kompiler Fortran memancarkan kode numerik yang sangat efisien. Di sisi lain, sejak hari-hari awal penggunaan komputer telah meledak dalam ribuan arah, tidak ada yang melibatkan analisis numerik, dan pengembangan bahasa pemrograman sebagian besar mengikuti dalam mengabaikan dunia 'nyata' [maafkan permainan kata].
SO: Ini hari ini, dan Anda mendapati diri Anda bekerja untuk sebuah perusahaan dengan produk yang cukup luas, sebagian besar ditulis dalam (katakanlah) Jawa (saya berbicara dari pengalaman pribadi di sini) . Tetapi Anda menemukan bahwa salah satu fitur inti dari produk ini akan mengeluarkan beberapa bentuk analisis numerik, dan semua kode terbaik untuk analisis tertentu sudah tersedia di internet - di Fortran. Jadi apa yang kamu lakukan? Anda mengunduh salah satu kode Fortran itu, mencari tahu antar muka [yaitu argumen dari subrutin teratas], menyiapkan pembungkus JNI untuknya dalam C, dan mengemasnya sebagai kelas Java. BAM! Anda baru saja harus mengembangkan dalam tiga bahasa sekaligus. [terutama jika Anda menemukan bahwa kode Fortran Anda menggunakan blok UMUM - yaitu penyimpanan statis - dan harus dimodifikasi untuk keamanan utas]
sumber
Karena pemrograman bukanlah satu tugas. Bahkan menciptakan produk bukanlah satu tugas. Ada beberapa jenis tugas yang paling baik diungkapkan dengan berbagai bahasa.
Untuk membuatnya lebih konkret, mari kita asumsikan sesuatu yang sederhana seperti aplikasi yang berdiri sendiri (ada lebih banyak tugas yang harus dilakukan untuk aplikasi yang didistribusikan).
Suatu produk harus
Bahasa yang mungkin baik untuk menulis run-time suatu produk sangat tidak mungkin sama baiknya untuk menyatukan produk. Dan seterusnya.
Namun bahkan proses penulisan suatu produk mungkin tidak dilakukan secara optimal dalam 1 bahasa.
Katakanlah ada banyak data terstruktur yang ditangani dalam produk. Apakah struktur data diketahui pada saat penulisan? Jika ya, Anda harus mengonfigurasi beberapa basis data pada saat penempatan. Ini dilakukan secara optimal dalam bahasa yang dapat menghasilkan bahasa yang akan dikompilasi dalam jangka waktu Anda.
Sekarang bagaimana jika struktur data dapat berubah dari waktu ke waktu? Daripada Anda memerlukan cara terstruktur untuk mengubah konstruksi data baru menjadi konfigurasi kode dan basis data. Ini paling baik dilakukan dalam bahasa lain.
Bisakah Anda melakukan semuanya dalam bahasa yang sama? Tentu. Tetapi keefektifan Anda ditentukan oleh seberapa cepat Anda bisa menyelesaikan suatu proyek dan seberapa tangguh untuk mengubahnya. Jika banyak pekerjaan Anda dapat diotomatisasi dengan alat yang sudah ada, maka apa yang Anda lakukan 3 bulan dapat dilakukan oleh orang lain dalam 2 hari. Tetapi seseorang akan menggunakan bahasa lain untuk mengotomatiskan apa yang akan Anda lakukan melalui pengulangan.
sumber
Pengembangan perangkat lunak telah berkembang ke titik di mana Anda dapat menggunakan berbagai bahasa pemrograman dalam proyek yang sama, dan Anda dapat membuatnya bekerja.
Lalu ada pertanyaan mengapa Anda akan menggunakan lebih dari satu bahasa.
Salah satu alasannya adalah bahwa bahasa menjadi usang dan perlahan diganti dengan yang lebih baru, dan jika Anda beruntung itu dapat dilakukan sedikit demi sedikit. Jadi proyek Anda akan memiliki campuran bahasa lama dan baru.
Alasan lain adalah situasi di mana bahasa X sangat banyak digunakan di platform A, bahasa Y sangat banyak digunakan di platform B, tetapi bahasa Z didukung di kedua platform. Jadi kode umum ditulis dalam bahasa Z, yang kemudian dikombinasikan dengan X atau Y, tergantung pada platform.
Dan orang-orang suka menggunakan kode yang ditulis oleh orang lain (dengan kata lain, kode yang tidak harus mereka habiskan untuk menulisnya sendiri). Mereka merasa bebas untuk menggunakan kode yang ditulis oleh orang lain dalam bahasa apa pun, dan kemudian menambahkan kode dalam bahasa yang mereka sukai.
sumber