Dunia programming sedang ramai dengan perdebatan sengit setelah pencipta bahasa Odin , Bill Hall , menerbitkan artikel provokatif berjudul Package Managers are Evil. Kritiknya telah memicu diskusi intens tentang apakah tools manajemen dependency otomatis membantu atau merugikan pengembangan software.
Argumen utama Hall menantang asumsi fundamental dalam programming modern. Dia mengklaim bahwa package manager mengotomatisasi hal yang salah - dependency hell - membuatnya lebih mudah bagi developer untuk mengakumulasi ribuan dependency tanpa memahami implikasinya. Diskusi ini telah mengungkap perpecahan mendalam dalam cara developer mendekati penggunaan ulang kode dan manajemen proyek.
Argumen Utama Menentang Package Manager:
- Mengotomatisasi dependency hell alih-alih mencegahnya
- Menyembunyikan kompleksitas dan biaya sebenarnya dari dependensi
- Memungkinkan akumulasi ribuan dependensi yang tidak terverifikasi
- Menciptakan kerentanan keamanan melalui kepercayaan buta
- Menyebabkan beban pemeliharaan dan tanggung jawab bug
Kontroversi Otomatisasi
Inti perdebatan berpusat pada apakah manajemen dependency harus otomatis atau manual. Hall berargumen bahwa package manager menyembunyikan kompleksitas dan membuat terlalu mudah untuk menambahkan dependency tanpa pertimbangan yang tepat. Dia menyarankan bahwa manajemen dependency manual memaksa developer untuk berpikir dengan hati-hati tentang setiap penambahan, berpotensi mencegah pohon dependency yang membengkak.
Respons komunitas mengungkap pengalaman yang beragam. Beberapa developer berbagi cerita tentang proyek Rust yang menarik puluhan dependency tak terduga dari hanya satu atau dua import langsung. Yang lain menunjukkan bahwa manajemen manual tidak dapat diskalakan untuk lingkungan enterprise besar di mana produk menggabungkan ratusan komponen dari berbagai tim di seluruh dunia.
Diskusi ini menyoroti ketegangan utama antara kemudahan developer dan maintainability proyek. Meskipun otomatisasi menghemat waktu, kritikus berargumen bahwa hal ini dapat menyebabkan situasi di mana proyek menjadi bergantung pada kode yang tidak pernah diperiksa atau dipahami oleh developer.
Cerita Dampak Dunia Nyata
Beberapa anggota komunitas berbagi contoh konkret masalah terkait dependency. Seorang developer menggambarkan menemukan banyak bug di SDL2 , sebuah library yang banyak digunakan, yang membuat tim mereka mempertimbangkan untuk menulis sistem windowing mereka sendiri dari awal. Yang lain menceritakan kesulitan mereproduksi build model neural yang telah dibuat tanpa manajemen dependency yang tepat.
Pengalaman bervariasi secara dramatis berdasarkan ekosistem programming. Developer Go melaporkan membutuhkan lebih sedikit package pihak ketiga karena standard library bahasa yang komprehensif, sementara developer JavaScript menggambarkan tantangan mengelola pohon dependency yang kompleks dalam aplikasi single-page.
Menyingkirkan npm dan melakukan hal-hal secara manual tidak akan membuat membangun SPA memiliki lebih sedikit dependency, build akan menjadi sangat lambat dan menyakitkan.
Komentar ini menangkap kekhawatiran umum - bahwa beberapa lingkungan pengembangan telah berevolusi untuk sangat bergantung pada ekosistem package sehingga manajemen manual menjadi tidak praktis.
Dimensi Kepercayaan dan Keamanan
Sebagian besar diskusi berfokus pada implikasi keamanan dari manajemen dependency otomatis. Anggota komunitas memperdebatkan apakah developer menempatkan terlalu banyak kepercayaan pada kode acak dari internet, dengan beberapa berargumen bahwa programmer dari masyarakat dengan kepercayaan tinggi menerapkan tingkat kepercayaan yang tidak tepat pada repositori kode online.
Percakapan mengungkap apa yang disebut beberapa orang sebagai efek Gell-Mann amnesia dalam programming - developer yang tidak mempercayai kode rekan mereka sendiri sambil secara membabi buta mempercayai package open-source dari penulis yang tidak dikenal. Paradoks ini menyoroti pertanyaan yang lebih luas tentang penilaian kualitas kode dan manajemen risiko dalam pengembangan software.
Beberapa peserta mencatat bahwa masalah keamanan, meskipun penting, bukan satu-satunya kekhawatiran. Tanggung jawab bug, beban maintenance, dan kompleksitas integrasi dapat sama-sama bermasalah untuk banyak proyek.
Pendekatan Alternatif dan Solusi
Perdebatan telah menghasilkan berbagai proposal untuk solusi jalan tengah. Beberapa menyarankan tooling yang lebih baik untuk auditing dependency, termasuk layanan scanning pihak ketiga yang terintegrasi ke dalam package manager. Yang lain mengadvokasi manajemen dependency yang lebih selektif, menggunakan package manager hanya untuk library substansial yang telah diverifikasi dengan baik daripada micro-package.
Developer enterprise menggambarkan penggunaan tools seperti Nix untuk manajemen dependency yang lebih andal, sementara yang lain menunjuk pada pendekatan seperti vendoring dependency dengan versi yang terkunci. Diskusi mengungkap bahwa konteks pengembangan yang berbeda - dari pengembangan game hingga sistem safety-critical - memiliki persyaratan dan batasan yang sangat berbeda.
Percakapan juga menyentuh peran standard library. Bahasa dengan fungsionalitas built-in yang komprehensif, seperti Go , tampaknya menghasilkan lebih sedikit dependency sprawl dibandingkan dengan yang memiliki standard library minimal yang mendorong fungsionalitas umum ke package eksternal.
Pendekatan Alternatif yang Dibahas:
- Manajemen dependensi manual dengan vendoring
- Menggunakan bahasa dengan pustaka standar yang komprehensif (contoh Go )
- Manajemen dependensi selektif hanya untuk paket-paket substansial
- Layanan audit pihak ketiga yang terintegrasi ke dalam package manager
- Tools seperti Nix untuk resolusi dependensi yang lebih andal
- Git subtrees sebagai pengganti submodules untuk manajemen dependensi
Kesimpulan
Perdebatan ini mencerminkan ketegangan yang lebih luas dalam pengembangan software antara pengembangan cepat dan maintainability jangka panjang. Meskipun package manager tidak diragukan lagi telah mempercepat pengembangan software dengan membuat penggunaan ulang kode lebih mudah, mereka juga telah memperkenalkan kategori masalah baru yang masih dipelajari industri untuk dikelola.
Diskusi menunjukkan bahwa daripada memandang package manager sebagai universally baik atau jahat, developer mungkin mendapat manfaat dari pendekatan yang lebih bernuansa yang mempertimbangkan konteks proyek, kemampuan tim, dan persyaratan maintenance jangka panjang. Saat industri programming terus matang, menemukan keseimbangan yang tepat antara otomatisasi dan kontrol manual tetap menjadi tantangan yang berkelanjutan.
Referensi: Package Managers are Evil