Apakah Perbandingan Bahasa Berarti? [Tutup]

Dr Bjarne Stroustrup dalam bukunya D&E mengatakan

Beberapa pengulas meminta saya untuk membandingkan C ++ dengan bahasa lain. Ini saya putuskan untuk tidak melakukannya. Dengan demikian, saya telah menegaskan kembali pandangan lama dan sangat dipegang: "Perbandingan bahasa jarang bermakna dan bahkan lebih jarang adil". Perbandingan yang baik dari bahasa pemrograman utama membutuhkan lebih banyak upaya daripada yang ingin dihabiskan oleh kebanyakan orang, pengalaman dalam berbagai bidang aplikasi, pemeliharaan yang kaku dari sudut pandang yang terpisah dan tidak memihak, dan rasa keadilan. Saya tidak punya waktu, dan sebagai perancang C ++, ketidakberpihakan saya tidak akan pernah sepenuhnya kredibel.

- Desain dan Evolusi C ++ (Bjarne Stroustrup)

Apakah Anda setuju dengan pernyataannya ini " Language comparisons are rarely meaningful and even less often fair"?

Secara pribadi saya berpikir bahwa membandingkan bahasa X dengan Y masuk akal karena memberi lebih banyak alasan untuk mencintai / membenci X / Y :-P

Apa yang kalian pikirkan?

Saya suka membandingkan bahasa pemrograman!

saya membandingkan java dengan angin hangat dengan sedikit hujan

saya membandingkan C # dengan hari musim semi yang indah dengan awan putih yang cukup halus untuk membuat langit bahagia

Saya membandingkan C dengan palu godam di ruangan yang penuh kaca

saya membandingkan C ++ dengan tas palu godam di dunia kristal

Saya membandingkan VB dengan mainan lama yang tenggelam di bak mandi

Saya membandingkan PL / 1 dengan landasan berkarat, melesat ke lantai

Anda membandingkannya dengan apa?

Saya pikir Stroustrup sepenuhnya benar. Dengan membandingkan dua bahasa secara memadai pada kemampuan teknisnya, mereka perlu cukup akrab dengan keduanya untuk menulis kode idiomatik dan menggunakan pola desain yang sama yang biasanya digunakan oleh para programmer yang sangat produktif dalam kedua bahasa tersebut. Seseorang yang tidak memiliki tingkat pengetahuan kedua bahasa tersebut dapat melihat hal-hal yang tidak secara eksplisit disediakan oleh bahasa yang tidak dia kenal, dan menganggap akan ada masalah sebagai hasilnya.

Misalnya, seseorang yang tidak menggunakan Python secara teratur dapat berasumsi bahwa pengguna Python secara teratur mengalami masalah karena lekukan. Atau seseorang yang tidak terbiasa dengan Common Lisp mungkin melihat kurangnya perpustakaan yang dipoles, tetapi tidak tahu bahwa FFI cukup kuat untuk menulis pembungkus untuk perpustakaan C dengan upaya nominal. Seseorang yang tidak terbiasa dengan Ruby mungkin melihat kurangnya pengetikan statis dan menganggap kesalahan ketik akan menjadi masalah besar. Akhirnya, seseorang yang tidak terbiasa dengan Haskell mungkin melihat kurangnya penugasan, dan menganggap itu tidak bisa menangani keadaan.

Sekarang semua ini mengasumsikan bahwa bahasa sebenarnya hanya dibandingkan pada kemampuan teknis mereka.

Bahasa adalah alat. Yang mengatakan, saya telah melihat alat yang benar-benar jelek sebelumnya. Tidak ada yang mau bekerja dengan palu yang kepalanya bisa terbang dan menabrak tukang kayu lain di perutnya. Demikian juga, jika Anda melihat palu rekan kerja Anda berada dalam kondisi seperti itu, Anda mungkin akan menghindari mereka ketika mereka menggunakannya.

Penting juga untuk benar-benar memahami alat apa itu. Anda tidak dapat menggunakan obeng dan palu secara bergantian (meskipun beberapa berusaha mati-matian). Sial, Anda bahkan tidak bisa menggunakan semua palu secara bergantian; Anda perlu kereta luncur untuk beberapa hal, palu untuk orang lain dan taktik untuk yang lain. Jika Anda menggunakan alat yang tidak pantas, maka yang terbaik, Anda akan melakukan pekerjaan yang lebih buruk, paling buruk Anda akan melukai diri sendiri atau rekan kerja.

Dengan kata lain, perbandingan bahasa berguna karena dapat mencegah kecelakaan di tempat kerja. Mengambil di atas dari metafora; sulit untuk mengetahui tanpa membandingkan apakah bahasa yang diberikan adalah palu godam, obeng, dremel atau gergaji meja, karena (tidak seperti dengan alat fisik) Anda tidak dapat benar-benar tahu hanya dengan melirik. Anda perlu memikirkan fitur-fitur yang ditawarkannya, melihatnya dalam aksi (dengan mencoba membaca bagian-bagian signifikan dari basis kode besar yang tertulis di dalamnya), dan idealnya, uji-drive sendiri juga. Hati-hati jangan sampai membuat kesalahan dengan hanya menulis Cobol dengan Python (misalnya). Anda perlu menggunakan bahasa baru secara idiomatis, yang berarti mempelajarinya dengan baik. Ini mungkin mengapa Bjarne mengatakan kebanyakan orang tidak berupaya cukup untuk perbandingan yang bermanfaat.

Jenis perbandingan yang dimulai dengan "Saya suka Blub" dan berlanjut dengan "Yah, saya suka Blub ++" sama sekali tidak berguna. Jika akhirnya memilih bahasa, yang benar-benar memberitahu Anda adalah siapa yang paling persuasif dalam kelompok tertentu dan / atau perusahaan bahasa mana yang memiliki anggaran iklan terbesar. Jika Anda menganalisis apa yang bisa dilakukan oleh suatu bahasa, tugas apa yang cocok untuknya, dan di mana kekurangannya tanpa menggunakan argumen yang tidak masuk akal atau bias pribadi, maka itu memang bisa bermanfaat.

Pengecualian itu, kecuali dalam beberapa perkecualian yang jarang (dan - jarang - seperti dalam "itu terjadi sekali atau dua kali dalam masa tata surya"), itu biasanya mengarah pada perang bahasa, dalam varian yang kurang lebih kuat, dan sangat jarang meninggalkan beberapa praktis dan kesimpulan yang bermanfaat.

Bahasa adalah alat, bukan agama. Anda tidak membandingkan palu dengan obeng, tetapi Anda menggunakan palu yang sesuai dengan tugas Anda & cara berpikir / pendidikan / tingkat abstraksi yang paling dibutuhkan. Juga, karena orang yang melakukan perbandingan bias oleh fakta bahwa ia tahu setidaknya satu dari dua, atau setidaknya lebih suka salah satu dari dua, sulit untuk menemukan kriteria yang benar-benar obyektif untuk membandingkannya (pengecualian ada).

Jika kami memperlakukan bahasa sebagai produk dan semua pengembang sebagai pasar, kami bisa sampai pada beberapa kesimpulan menarik:

1. Produk tidak selalu bersaing. Misalnya, Haskell tidak memecahkan masalah yang sama seperti Java yang tidak menyelesaikan masalah yang sama seperti Majelis yang tidak menyelesaikan masalah yang sama seperti Prolog. Satu pengembang, dalam situasi yang berbeda, dapat menggunakan semua bahasa ini. Perbandingan menyiratkan persaingan untuk keunggulan. Karena itu, tidak masuk akal untuk membandingkan bahasa yang tidak bersaing.
2. Visibilitas di pasar berarti produk telah membuktikan dirinya bermanfaat bagi seseorang. Artinya, Anda dapat membandingkan Ruby dan Python semau Anda - orang selalu melakukannya. Entah bagaimana, itu tampaknya tidak mengubah pikiran siapa pun (atau jika itu berubah, jumlah orang yang sama berubah pikiran ke arah lain). Dalam hal yang penting, Ruby dan Python setara. Ini seperti dua perusahaan soda raksasa yang membuat perbandingan "ilmiah" dari produk mereka. Satu studi menunjukkan Coca-cola lebih unggul sementara yang lain menunjukkan Pepsi lebih unggul. Bahkan jika datanya dapat diandalkan, itu tidak berarti apa-apa. Kita semua tahu bahwa itu adalah soda (bahasa pemrograman) yang sangat bagus dan hanya sedikit yang sesuai dengan selera pribadi saya.
3. Perbandingan bahasa adalah bentuk pemasaran geek. Jika ada tempat yang sangat objektif untuk memulai perbandingan, mereka mungkin berguna. Tentu saja tidak. Siapa pun yang ingin membuat perbandingan sedang mencoba untuk mengkonfirmasi bias yang ada. Mereka mencoba menjual bahasa. Sekali lagi, jika C ++ sangat buruk atau VB sangat buruk atau Erlang sangat buruk, lalu mengapa orang menggunakannya? Anda dapat membuat semua klaim yang Anda inginkan, tetapi itu tidak menghentikan mereka untuk menjadi berguna. Asumsi kami adalah bahwa orang terlalu bodoh untuk melihat kebenaran di depan mereka, tetapi kebenaran kemungkinan bahwa "pasar" lebih kompleks daripada yang kita sadari. Perbandingan memberi tahu kami lebih banyak tentang orang yang melakukan perbandingan daripada membandingkan produk yang dibandingkan.

Stroustrup sepenuhnya benar.

Kebanyakan "perbandingan bahasa" dilakukan dengan hasil tertentu dalam pikiran, yaitu untuk "menunjukkan" bahwa yang satu lebih "unggul" dari yang lain.

Seringkali ini berarti menulis sepotong kode dalam kedua bahasa dan mengukur kinerja yang dapat dieksekusi, menulis satu bahasa yang sangat dioptimalkan dan yang lainnya sengaja untuk kinerja yang buruk. Begitulah mitos "Jawa lambat" terus diabadikan. "Tes" untuk "membuktikan" itu ditulis dengan sengaja untuk tidak mengukur kinerja menjalankan kode Java tetapi waktu startup JVM. Ambil contoh operasi matematika sederhana dan putar 100 kali, lakukan itu di Java dan C ++, kompilasi versi C ++ dengan optimisasi dihidupkan, versi Java tanpa flag optimasi, kemudian jalankan kedua versi yang dapat dieksekusi. Kelas Java akan berjalan jauh lebih lama daripada C ++ yang dapat dieksekusi, hanya karena waktu startup JVM. Ini tidak menunjukkan bahwa "Java lambat" tetapi waktu startup JVM berarti Java bukan alat yang tepat untuk proses yang berjalan sangat singkat (tidak ada bahasa yang ditafsirkan, atau apa pun yang membutuhkan pemuatan runtime). Jika tes ditulis dengan benar untuk menjalankan selama beberapa jam dengan basis kode dan sistem kompiler menggunakan tingkat optimisasi yang setara, hasilnya sangat berbeda (mungkin menunjukkan kinerja yang sangat mirip).

Dan itu hanya satu contoh (yang saya kenal).

Sebagai manajer proyek, Anda harus membuat beberapa perbandingan untuk memilih bahasa tempat perangkat lunak Anda akan dikodekan. Kriteria mungkin tidak teknis:

• Apakah bahasa memadai untuk tugas tersebut
• Apakah bahasa tersedia di semua platform target
• Kualitas, keandalan, dan biaya penyusun
• Apakah ada programmer yang tahu bahasa itu, apakah mereka kompeten, mahal, kreatif