Mengapa beberapa bahasa pemrograman digunakan dalam pengembangan satu produk atau perangkat lunak?


114

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.


14
Sebagai sesama mahasiswa pascasarjana di bidang teknik komputer, saya akan menambahkan bahwa untuk kode penelitian khususnya, sering kali soal "bahasa apa yang paling dikenal penulis (mahasiswa) ketika mereka mulai". Proyek penelitian, terutama sekali yang tidak mengarah ke proyek penelitian yang lebih besar, cenderung menilai hasil lebih dari "kebenaran" (dalam pengalaman saya).
tonysdg

16
@tonysdg: Saya akan mengatakan bahwa "kebenaran" cenderung lebih relevan di dunia akademis, tidak kurang. Apa yang umumnya tidak relevan adalah rawatan, pengalaman pengguna, dan / atau dokumentasi. Bahasa campuran khususnya mempengaruhi kemampuan pemeliharaan; itu membatasi jumlah pengelola yang memenuhi syarat.
MSalters

2
@ MSalters: Maintainability adalah kata yang saya pikir saya cari pada saat itu --- Saya setuju dengan semua yang Anda tulis!
tonysdg

19
Alat yang berbeda untuk tugas yang berbeda. Anda akan melihat bahwa arsitek bangunan dan insinyur menggunakan alat yang berbeda untuk membangun satu rumah.
Paul D. Waite

17
Ketika Anda pergi berlibur, dari rumah Anda ke bandara lalu ke bandara asing lalu ke hotel lalu ke pantai, apakah Anda menggunakan moda transportasi yang sama untuk setiap perjalanan?
Lightness Races di Orbit

Jawaban:


17

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:

  1. Manfaat biaya menggunakan kembali kode yang ditulis dalam bahasa lain;
  2. Kebutuhan untuk memasukkan dan mengakomodasi kode warisan;
  3. Ketersediaan coders untuk bahasa tertentu;
  4. Kebutuhan akan bahasa khusus untuk kebutuhan khusus;
  5. Bias bahasa lama; dan
  6. Manajemen proyek yang buruk (penggunaan multi-bahasa yang tidak terencana).

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!


Saya setuju dengan itu semua. Sementara jawaban Basile berfokus terutama pada masalah kinerja dan ekspresibilitas, jawaban Anda membantu siapa pun memahami perspektif manajemen di balik memilih pemrograman polyglot.
Parth Patel

@ ParthPatel Saya pikir Anda harus menerima jawaban ini, itu bungkus mandiri terbaik di sini
leftaround sekitar

2
+1: tetapi Anda lupa Ego. Banyak orang menolak untuk belajar bahasa baru dan tetap dengan apa yang mereka ketahui. Tingkat kedewasaan yang berbeda dengan banyak tim ini dapat menyebabkan banyak teknologi berbeda dalam satu proyek
Daveo

1
Alasan 7, mencoba membuat departemen TI terlihat seksi untuk keperluan merekrut. Tidak main-main, pada proyek .Net, kami akhirnya harus mengganti titik akhir tunggal dari layanan yang ada, untuk menggunakan layanan yang sama sekali baru di Go, supaya mereka bisa memasukkan "polyglot" dalam penambahan pekerjaan!
Chris Lee

1
Heh! Saya tidak bisa tidak setuju bahwa menggunakan banyak bahasa merupakan daya tarik bagi orang-orang yang khawatir bahwa mereka mungkin akan menemui jalan buntu, jenis pekerjaan yang hanya COBOL. Ini adalah pertama kalinya saya mendengar tentang bahasa yang ditambahkan hanya dan secara khusus untuk tujuan itu, tetapi tentu saja ada banyak lingkungan di mana memiliki berbagai alat dan bahasa yang lebih besar dipandang sebagai indikasi bahwa mereka bekerja dengan teknologi terbaru, dan karenanya merupakan tempat yang lebih progresif untuk bekerja. Contoh yang bagus, terima kasih!
Terry Bollinger

158

Sepertinya saya tidak dapat memahami alasan mengapa beberapa bahasa pemrograman digunakan dalam produk atau perangkat lunak yang sama?

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


6
Bagi saya, ini jawaban yang benar. Anda dapat mengambil misalnya perakitan rutin dalam program C. Shell UNIX dipenuhi dengan banyak bahasa pemrograman, dan Anda akan sering menemukan awk(yang merupakan bahasa pemrograman lain) yang digunakan dalam skrip bash, hanya karena ia lebih sesuai untuk tugas tersebut. @titik amon masih berdiri.
MayeulC

8
BTW, seorang programmer hebat kadang-kadang dapat menghapus baris kode ... (dengan mengganti banyak baris kode jelek dengan beberapa baris bagus)
Basile Starynkevitch

12
Jawaban yang bagus, tetapi satu permintaan: Saya menghargai keinginan untuk menunjukkan "selain" dengan menghadirkannya dengan kurang jelas, tapi tolong jangan menyalahgunakan tag SUP HTML hanya karena memiliki efek samping rendering dalam font yang lebih kecil. Itu harus menjadi mimpi buruk aksesibilitas, dan sebagai standar HTML5 memperingatkan, "Elemen-elemen ini harus digunakan hanya untuk menandai konvensi tipografi dengan makna tertentu, bukan untuk presentasi tipografi demi presentasi. [...] gunakan elemen-elemen ini hanya jika tidak adanya elemen-elemen itu akan mengubah makna konten. "
FeRD

4
@FeRD: dihapus <sup>tetapi dengan penyesalan
Basile Starynkevitch

6
@BasileStarynkevitch Dihormati. Seperti yang saya katakan, saya menghargai maksudnya, dan sebagai seorang penulis yang terlalu bertele-tele, cenderung ruwet, saya tentu berharap StackExchange menyediakan metode yang didukung untuk menata teks yang lebih kecil, atau mungkin runtuh dalam wadah klik untuk membuka. Tetapi superskrip sepanjang paragraf bukanlah jawaban atas kekurangan itu.
FeRD

29

Banyak proyek tidak dibangun dengan banyak bahasa pemrograman. Namun, adalah umum untuk menggunakan skrip dalam bahasa lain untuk membantu dengan perangkat lunak.

  • Alat administrasi yang merupakan program terpisah terkadang ditulis dalam bahasa yang berbeda.
  • Perpustakaan dan API sering menawarkan binding untuk berbagai bahasa, sehingga pengembang dapat menggunakan bahasa apa pun yang mereka inginkan.
  • Bangun skrip dan skrip pengembangan terkait sering menggunakan bahasa khusus.
  • Tes ujung ke ujung suatu aplikasi tidak perlu menggunakan bahasa yang sama.

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.


3
Ini melengkapi jawaban @ Basile. Skrip perl dari kernel Linux bukan bagian dari kernel, juga bukan Makefile. Tidak ada untungnya menggunakan C untuk ini. Selain itu, skrip perl tersebut dapat digunakan secara independen dari kernel Linux. Cukup sering, itu dapat dianggap sebagai proyek yang terkait erat, namun berbeda . Anda biasanya akan menggunakan satu bahasa untuk satu tugas.
MayeulC

20

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.


20

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.


Akan lebih baik untuk memberi tahu lebih banyak tentang produk perangkat lunak ini: domain industri apa (robot bedah saraf yang tidak sama dengan perdagangan frekuensi tinggi, misalnya)? Berapa perkiraan ukuran (dalam jutaan baris kode)? Ukuran tim apa?
Basile Starynkevitch

@ BasileStarynkevitch: menambahkan detail.
John Dallman

Ini. Inilah sebabnya mengapa proyek memiliki banyak bahasa dari yang baik ke yang buruk hingga yang jelek.
Jared Smith

15

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.


MVC FTW! Bahkan turun ke hanya memiliki satu inti lintas platform dengan aplikasi pembungkus untuk setiap OS / lingkungan ... atau di dunia modern konektivitas memindahkannya ke arsitektur klien / server
ivanivan

1
Ini cocok dengan pengalaman saya sendiri. Setiap proyek dengan ukuran substansial yang telah saya kerjakan telah menggunakan banyak bahasa, dan tidak pernah begitu banyaknya bahasa yang memberikan manfaat. Alasannya selalu karena bagian-bagian tertentu harus ditulis dalam bahasa tertentu untuk berinteraksi dengan alat-alat tertentu.
Owen

Sebagai mantan pengembang iOS, saya dapat mengonfirmasi bahwa kami melakukan ini. Kami memiliki API yang ditulis dalam PHP yang dikomunikasikan dalam JSON, front-end web yang ditulis dalam PHP yang juga memiliki bagian JavaScript / HTML5, front-end Android yang ditulis dalam Java dan front-end iOS yang ditulis dalam Objective-C . Kemudian, proyek-proyek baru ditulis dalam Swift, tetapi kerangka kerja internal kami masih ditulis dalam Objective-C. Jadi pada satu titik salah satu aplikasi kami ditulis dalam PHP, Java, Objective-C, Swift, JavaScript dan HTML5 dan tersedia di 3 platform.
Belle-Sophie

10

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:

  1. Orang-orang memiliki pengalaman dan tingkat minat yang berbeda dalam bahasa pemrograman yang berbeda. - Mengizinkan orang untuk bekerja dalam bahasa yang mereka sukai dan cakap dalam keadaan tertentu dapat memberikan hasil akhir yang lebih baik daripada memaksa mereka menggunakan bahasa yang sama.
  2. Basis kode besar dibangun dalam jangka waktu yang lama oleh orang yang berbeda. - Tidak ada cara untuk mendapatkan dana atau jumlah sukarelawan yang diperlukan untuk menulis ulang seluruh proyek begitu bahasa yang lebih cocok untuk itu keluar.

Dan tentu saja sering ada bagian spesifik dari aplikasi yang memiliki kebutuhan yang sepenuhnya berbeda, seperti:

  • Area sensitif kinerja dikembangkan dalam bahasa yang dikompilasi. Bahasa contoh: C ++
  • Area yang perlu murah, mudah diubah, dan berpotensi disesuaikan, dikembangkan dalam bahasa scripting. Bahasa contoh: Lua.
  • Layout GUI. Bahasa contoh: HTML
  • Pemasang. Bahasa / alat contoh: WiX.
  • Membangun. Bahasa / alat contoh: Terlalu banyak untuk dicantumkan, biasanya beberapa di antaranya sekaligus.

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.


8
HTML bukan bahasa pemrograman
Bergi

1
@Bergi Benar. Peter tidak mengklaim itu. Ini adalah bahasa markup.
Belle-Sophie

1
HTML, XAML, QML, dll. Adalah bahasa yang digunakan oleh programmer dalam proyek perangkat lunak untuk memberi tahu komputer apa yang harus dilakukan - bahasa biasanya tidak sepenuhnya diperlukan karena programmer secara teoritis dapat menulis seluruh proyek, termasuk UI, dalam satu bahasa. Itulah yang membuatnya relevan dalam konteks pertanyaan ini.
Peter

5

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.


5

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.


Saya terkejut tidak ada yang menyebutkan SQL (atau bahasa query pilihan Anda), sebagian besar aplikasi sekarang memiliki setidaknya beberapa jenis arsitektur "stack".
user3067860

3

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]


4
Atau inti komputasi FORTRAN yang teruji dengan baik akan ditingkatkan dengan memanggil suatu titik suatu algoritma baru yang tergantung pada melakukan semacam tumpukan pada pointer, yang telah Anda tulis dalam C. Dan Anda memiliki file input yang kompleks untuk dipindai, sehingga Anda menulis pemindai dalam fleksibel. Oh, dan mungkin Anda ingin GUI di atasnya, yang harus Anda hubungi dari C ++. Atau klien benar-benar ingin menyebut semuanya sebagai subrutin Matlab ...
jamesqf

3

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

  • tertulis
  • disatukan (ini melibatkan kompilasi dan pengumpulan sumber daya seperti gambar, font, dll untuk penyebaran)
  • dikerahkan
  • dikonfigurasi
  • dipantau

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.


“Bahasa yang mungkin baik untuk menulis run-time suatu produk sangat tidak mungkin sama baiknya” ... bahasa pemrograman tidak keluar dari proses acak, jadi agak aneh untuk berbicara tentang kemungkinan seperti ini. Bahasa pemrograman dirancang untuk menyelesaikan beberapa tugas. Maksud Anda adalah bahwa bahasa tidak mungkin juga, secara tidak sengaja , memecahkan masalah lain juga yang tidak dirancang untuk diselesaikan. Saya berpendapat bahwa esensi pemrograman adalah abstrak semua masalah yang ingin diselesaikan, dan bahasa yang dirancang dengan sangat baik harus sama baiknya untuk tugas apa pun.
leftaround sekitar

@leftaroundabout itu adalah kesalahan umum untuk membingungkan apa yang bisa dilakukan bahasa dan apa yang diekspresikan dengan baik. Tujuan dari bahasa tingkat tinggi bukanlah untuk memecahkan masalah. Itu untuk bertindak sebagai sintaks untuk mengekspresikan solusi untuk masalah dengan cara di mana beberapa alat dapat mengubah ekspresi ini menjadi tugas yang harus dilakukan oleh komputer. Mengingat hal ini, penting untuk diingat bahwa pekerjaan pengungkapan yang sebenarnya dilakukan oleh orang-orang. Dan orang-orang menggunakan abstraksi yang berbeda untuk menggambarkan solusi masalah dari domain yang berbeda.
grovkin

Tentu orang menggunakan abstraksi yang berbeda. Maksud saya adalah bahwa bahasa yang baik harus dapat mengekspresikan semua abstraksi ini.
leftaround sekitar

@ Leftaroundabout, tidak sama sekali. Mengekspresikan sesuatu dengan baik membutuhkan kemampuan untuk mengarahkan perhatian pada hal tersebut. Mencoba mengekspresikan semua jenis abstraksi dengan baik berarti membawa perhatian pada mereka semua. Dan itu akan menghamburkan perhatian dan menyebabkan ide-ide itu diekspresikan dengan buruk. Tidak ada salahnya memilih apa yang harus ditekankan dan berkonsentrasi pada hal itu.
grovkin

Mampu mengarahkan perhatian ke suatu tempat bukanlah hal yang sama dengan benar-benar melakukannya.
leftaround sekitar

1

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.


8
Tentang kalimat pertama: program bahasa campuran telah menjadi hal selama lebih dari 50 tahun.
Blrfl
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.