Bahasa Pemrograman C (Masalah pada bahasa C)

• Masalah memori: tidak mendapat bantuan dari alat apa pun seperti GC, analisis statis, dan sebagainya.

• Perilaku tak terdefinisi: cenderung digunakan terutama pada lingkungan tingkat rendah dan memiliki tuntutan optimasi yang tinggi, sehingga perilaku tak terdefinisi bertambah demi optimasi. Gagal meraih dua tujuan sekaligus, yaitu performa tingkat rendah dan portabilitas.

• Tidak cocok untuk pemrograman skala besar: tidak adanya modul dan manajer paket. Bahkan hal yang banyak digunakan seperti #pragma once pun tidak memiliki standar.

[ffdd270]

Terima kasih telah membagikan tulisan yang bagus. Namun, ada satu hal kecil yang membuat saya penasaran, jadi saya meninggalkan komentar.

• Mungkin memang belum ada saat Anda pertama kali menulisnya pada 2011, tetapi sekarang sudah muncul beberapa package manager untuk C. Ada Conan, dan juga vcpkg dari MS. Memang masih ada beberapa kekurangan dibanding npm (vcpkg untuk version management masih berlabel beta, dan conan memiliki lebih sedikit referensi dibanding vcpkg), tetapi kondisinya sudah jauh lebih baik daripada masa ketika belum ada sama sekali.

[lifthrasiir]

Saya penulis artikel ini (haha...). Saat ini situsnya masih dalam status soft release dan saya menulis artikel secara eksperimental, jadi mohon maklum bahwa isinya bisa terus direvisi. Saya juga melacaknya sendiri, tetapi saya juga menerima masukan lewat email, jadi silakan dijadikan acuan.

Seperti yang Anda sebutkan, vcpkg saat ini tampak sebagai package manager yang paling menjanjikan, dan Conan juga sebenarnya merupakan proyek yang sudah ada sejak cukup lama (tidak terlalu jauh dari waktu penulisan aslinya). Namun, karakteristik terbesar dari proyek-proyek ini adalah bahwa mereka sendiri tidak memiliki build system, melainkan meta build system. (Jika mengingat bahwa CMake sendiri, yang menjadi target dukungan utama, juga merupakan meta build system, mungkin ini bisa disebut meta-meta build system...) Karena itu, sulit bagi mereka untuk benar-benar menyelesaikan masalah yang muncul dari build system itu sendiri. Pada vcpkg terlihat ada jejak pertimbangan yang lebih matang; misalnya, jika sebuah proyek memerlukan versi berbeda dari dependensi yang sama (melalui jalur dependensi yang berbeda), enlistment dapat dipecah. Namun, ini tidak lebih dari cara untuk mengakali keterbatasan build system itu sendiri. Sebagai perbandingan, dalam Rust dan Cargo, pada kasus seperti ini kedua versi tersebut bisa dibangun sekaligus dan tidak ada masalah untuk dirujuk dari satu crate.

Selain itu, saat ini vcpkg tampaknya bahkan belum memiliki tingkat integrasi alat setara NuGet di Visual Studio (hanya integrasi MSBuild saja...), dan juga sepertinya belum terlalu terintegrasi dengan package manager distribusi Linux/BSD. Masalah ini juga merupakan tantangan terbesar yang dihadapi package manager per bahasa saat ini; bahasa-bahasa baru seperti Rust menyelesaikannya satu per satu, tetapi untuk package manager C/C++ seharusnya integrasi dengan sistem yang sudah ada menjadi tujuan utama, dan itu masih berjalan lambat. Baru setelah bagian ini terselesaikan, barulah sistem seperti vcpkg bisa disebut sebagai alat yang dapat digunakan secara umum dalam pengembangan C/C++. Fakta bahwa itu belum terjadi adalah alasan utama saya menilai rendah sistem paket dalam artikel tersebut. (Menjamurnya single-file library yang saya sebutkan dalam artikel juga merupakan bukti tidak langsung bahwa sistem seperti vcpkg belum terlalu berhasil menarik perhatian.)

[ffdd270]

Terima kasih atas jawabannya yang sangat rinci. Memang pada dasarnya itu adalah build = hm=.. jadi berbeda dengan npm atau package manager lain, tampaknya ada batas yang tidak bisa dikejar. vcpkg belakangan ini juga tampak banyak memikirkan soal versi, tetapi sepertinya tidak akan mudah untuk mengatasinya.

Saya juga sempat berpikir apakah sistem modul di C++20 bisa menjadi jawaban untuk masalah ini... tetapi kalau begitu cakupannya jadi melampaui bahasa C (...). Sepertinya yang tersisa untuk bahasa C hanyalah jalan berduri. Kalaupun C20 ditetapkan sekarang, tingkat peralihan versinya pun mungkin tidak akan setinggi C++..

[functor]

Terima kasih atas pendapat yang bagus.

Menurut pemikiran pribadi saya, kurang lebih begini. Adanya beberapa package manager untuk C adalah hal yang baik, tetapi masalahnya tampaknya package manager seperti ini tidak banyak digunakan. Lebih tepatnya, karena warisan legacy C sudah sangat besar, saya merasa kita mungkin sudah terlanjur berjalan terlalu jauh untuk menyelesaikan masalah-masalah yang disebutkan di atas. Karena itu, bukankah jadi semakin banyak upaya untuk beralih ke bahasa baru seperti Rust.

[ffdd270]

Setelah mendengar penjelasannya dan memikirkannya lagi, sepertinya package manager di atas lebih berfokus pada memperpanjang umur para programmer yang memang harus memakai bahasa C, ketimbang memperpanjang umur bahasa C itu sendiri.

Sekarang, saat waktunya pindah ke rumah baru (C++, Rust...), ketika kita membutuhkan perabot lama seperti OpenGL atau Lua yang dulu ada di rumah lama, tanpa package manager semuanya harus dipindahkan dengan tangan (harus linking, make, pusing karena versi DLL atau lib tidak cocok... lihat error LNK sampai rasanya mau lompat... ) Tapi sekarang, karena sudah ada package manager, semuanya bisa dipindahkan rapi seperti jasa pindahan profesional. Karena yang sudah dibuat selama ini memang sangat banyak, tentu ada kalanya tetap perlu dipakai juga di rumah baru...

Kalau sekarang yang lebih besar justru nilai dari pengalaman dan akumulasi yang menumpuk selama ini daripada kelebihan bahasanya sendiri, rasanya memang benar-benar terasa kalau ini bahasa yang sedang sekarat(...

[galadbran]

Dalam banyak hal, tampaknya Rust paling kuat memiliki citra sebagai next C/C++. (Di antara beberapa bahasa yang dianggap sebagai next, ada juga kesan bahwa Rust relatif paling kompleks... wkwk)

[dalinaum]

Sepertinya bukan hanya dari sisi citra, Rust juga memang sulit dalam praktiknya.