Hobi saya adalah membuka "Filsafat UNIX" McIlroy pada satu monitor sambil membaca mana pada yang lain.

Yang pertama dari prinsip-prinsip McIlroy sering diulangi sebagai "Lakukan satu hal, tetapi lakukan dengan baik." Ini adalah singkatan dari kata-katanya, "Buat program yang melakukan satu hal dengan baik." Untuk pekerjaan baru, buat program baru, daripada menyulitkan yang lama dengan menambahkan "fungsi" baru. "

McIlroy memberi contoh:

Tampaknya mengejutkan bagi orang luar bahwa kompiler UNIX tidak mengeluarkan daftar: pencetakan lebih baik dilakukan dan lebih fleksibel dikonfigurasi menggunakan program terpisah.

Jika Anda membuka bantuan untuk ls, maka itu dimulai dengan

ls [-ABCFGHLOPRSTUW@abcdefghiklmnopqrstuwx1] [file ...]

Yaitu, bendera satu huruf untuk lsmenyertakan semua huruf kecil, kecuali untuk {jvyz}14 huruf besar, @dan 1. Ini adalah 22 + 14 + 2 = 38 hanya opsi karakter tunggal.

Di Ubuntu 17, bantuan untuk lstidak akan menampilkan ringkasan normal, tetapi Anda akan melihat bahwa lsada 58 opsi (termasuk --helpdan --version).

Mari kita lihat apakah ini adalah situasi yang unik atau keadaan normal. Mari kita membuat daftar beberapa perintah umum, diurutkan berdasarkan frekuensi penggunaan.

Tabel menunjukkan jumlah opsi baris perintah untuk berbagai perintah v7 Unix (1979), slackware 3.1 (1996), ubuntu 12 (2015), dan ubuntu 17 (2017). Semakin banyak parameter, semakin gelap sel (pada skala logaritmik).

Kami melihat bahwa selama bertahun-tahun jumlah opsi meningkat secara dramatis: sebagai suatu peraturan, rekaman gelap dari kiri ke kanan (lebih banyak pilihan), dan tidak ada kasus ketika catatan menjadi lebih ringan (lebih sedikit pilihan).

McIlroy telah lama mengutuk peningkatan jumlah opsi, ukuran dan fungsionalitas keseluruhan tim ¹ :

, , Linux … []. , , . , , … Unix : « ? ?» , - , . , , , . … , .

Ironisnya, salah satu alasan meningkatnya jumlah opsi baris perintah adalah pepatah McIlroy lainnya: "Tulis program untuk memproses stream teks karena ini adalah antarmuka universal" (lihat lssebagai contoh).

Jika data atau objek terstruktur ditransmisikan, pemformatan dapat dibiarkan hingga tahap akhir. Tetapi dalam kasus teks biasa, format dan konten dicampur; karena pemformatan hanya dapat dilakukan dengan mem-parsing konten, perintah biasanya menambahkan opsi pemformatan untuk kenyamanan. Selain itu, format dapat dilakukan ketika pengguna menerapkan pengetahuan tentang struktur data, dan "mengkodekan" pengetahuan tentang argumen untuk cut, awk,seddll. (pengguna juga menggunakan pengetahuannya tentang cara kerja program ini dengan pemformatan, karena berbeda untuk program yang berbeda, jadi pengguna harus tahu, misalnya, bagaimana cut -f4 perbedaannya dari awk '{ print $4 }^2).) Ini jauh lebih merepotkan daripada melewatkan satu atau dua argumen ke perintah berikutnya secara berurutan, dan ini mentransfer kompleksitas alat kepada pengguna.

Terkadang orang mengatakan bahwa mereka tidak ingin mendukung data terstruktur, karena dengan itu dalam alat universal seseorang harus mendukung beberapa format. Tetapi mereka sudah harus mendukung beberapa format untuk membuat alat universal. Beberapa perintah standar tidak dapat membaca output dari perintah lain karena mereka menggunakan format yang berbeda. Misalnya, wc -wUnicode tidak menanganinya dengan benar, dll. Mengatakan bahwa "teks" adalah format universal sama dengan mengatakan bahwa "biner" adalah format universal.

Dikatakan bahwa tidak ada alternatif untuk komplikasi seperti alat baris perintah. Tetapi orang-orang yang mengatakan itu belum pernah mencoba alternatif, seperti PowerShell. Saya memiliki banyak keluhan tentang PowerShell, tetapi transfer data terstruktur dan kemampuan untuk dengan mudah bekerja dengan data terstruktur tanpa harus menyimpan metadata di kepala saya sehingga saya dapat mentransfernya ke alat baris perintah yang tepat di tempat yang tepat di pipa bukan salah satu keluhan saya ³ .

Ketika Anda diberi tahu bahwa program harus sederhana dan kompatibel saat memproses teks, orang-orang ini berpura-pura bahwa data teks tidak memiliki struktur untuk diuraikan ⁴ . Dalam beberapa kasus, kita dapat menganggap semuanya sebagai satu baris, dipisahkan oleh spasi, atau sebagai tabel dengan pemisah baris dan kolom ( dengan perilaku yang, tentu saja, tidak konsisten dengan alat lain ). Ini menambah sedikit masalah. Masih ada kasus di mana serialisasi data ke dalam format teks biasa menambah kerumitan yang signifikan, karena karena struktur data, serialisasi sederhana ke teks selanjutnya membutuhkan upaya penguraian yang signifikan untuk mengasimilasi kembali data dengan cara yang bermakna.

Alasan lain mengapa tim sekarang memiliki lebih banyak pilihan adalah karena orang telah menambahkan tanda nyaman untuk fungsionalitas yang dapat diimplementasikan oleh saluran pipa dari beberapa tim. Praktek ini telah berlangsung sejak Unix v7, di mana dilssebuah opsi tampaknya mengubah urutan sortir (walaupun ini bisa dilakukan dengan meneruskan output ke tac).

Seiring waktu, semata-mata untuk kenyamanan, menambahkan parameter tambahan. Misalnya, perintah mvyang awalnya tanpa parameter sekarang dapat memindahkan file dan secara bersamaan membuat salinan cadangan (tiga opsi; dua cara berbeda untuk menentukan cadangan, salah satunya mengambil argumen dan yang lain tidak mengambil argumen, membaca argumen implisit dari variabel lingkungan VERSION_CONTROL; opsi lain memungkinkan Anda mengganti sufiks cadangan default). Sekarang mvmasih ada opsi untuk tidak pernah menimpa file atau menimpa hanya file yang lebih baru.

mkdirprogram lain yang sebelumnya tidak memiliki opsi. Hari ini, semua benderanya, dengan pengecualian opsi keamanan untuk SELinux atau SMACK, serta nomor bantuan dan versi, ditambahkan hanya untuk kenyamanan: mengatur izin untuk direktori baru dan membuat direktori induk jika tidak ada.

Pada tailawalnya hanya ada satu opsi -number, yang menunjukkan titik awal untuk pekerjaan tersebut. Kemudian kami menambahkan pemformatan dan opsi untuk kenyamanan pemformatan. Bendera -zmenggantikan pemisah garis dengan null. Berikut adalah contoh lain dari opsi yang ditambahkan untuk kenyamanan: -funtuk mencetak ketika perubahan baru muncul, -suntuk mengatur interval waktu habis antara memeriksa perubahan / kode> -f, dan juga -retryuntuk mencoba lagi mengakses file jika tidak tersedia.

McIlroy mengkritik pengembang karena menambahkan semua opsi ini, tapi saya pribadi merasa lebih baik. Meskipun saya belum pernah menggunakan beberapa dari mereka, saya jarang menggunakan yang lain, tetapi ini adalah keindahan dari parameter baris perintah - tidak seperti antarmuka grafis, menambahkan parameter ini tidak mengacaukan antarmuka. Ya, mana dan bantu membengkak, tetapi di era Google dan Stackoverflow, dalam hal apa pun, banyak yang hanya google pertanyaan, daripada membaca mana.

Tentu saja, menambahkan opsi meningkatkan beban pada pengelola. Tetapi ini adalah pembayaran yang adil untuk manfaat yang mereka bawa. Mengingat rasio jumlah pemelihara dan pengguna, adalah logis untuk menempatkan beban tambahan pada yang pertama, dan bukan yang terakhir. Ini mirip dengan pernyataan Gary Bernhardt bahwa adalah bijaksana untuk berlatih kinerja 50 kali. Jika audiensnya 300 orang, maka rasio waktu yang dihabiskan untuk menonton pertunjukan dibandingkan dengan waktu yang dihabiskan untuk latihan tetap 6: 1. Untuk alat baris perintah populer, rasio ini bahkan lebih ekstrem.

Beberapa orang mungkin berpendapat bahwa semua opsi tambahan ini membebani pengguna. Ini tidak sepenuhnya salah, tetapi beban kompleksitas ini akan selalu ada. Pertanyaannya adalah di mana tepatnya. Jika Anda membayangkan bahwa toolkit baris perintah bersama dengan shell membentuk bahasa di mana setiap orang dapat menulis metode baru, dan dalam hal popularitas, metode ini secara efektif ditambahkan ke pustaka standar, dan standar ditentukan oleh aksioma seperti "Menulis program untuk memproses aliran teks, karena universal antarmuka ", maka bahasa akan berubah menjadi kekacauan tulis-satunya yang tidak jelas, jika Anda menerimanya secara keseluruhan. Setidaknya, berkat alat dengan berbagai pilihan dan fungsi, pengguna Unix dapat mengganti satu set alat yang sangat tidak konsisten dengan hanya satu set alat yang besar,walaupun mereka tidak konsisten satu sama lain dari luar, mereka memiliki beberapa konsistensi internal.

McIlroy menyiratkan kurangnya perhatian dalam kotak peralatan. Seperti, para pendiri Unix harus duduk di ruangan yang sama dan berpikir dengan hati-hati sampai mereka datang dengan seperangkat alat berurutan "kesederhanaan luar biasa." Tapi itu tidak akan skala, filosofi Unix itu sendiri pasti menyebabkan kekacauan yang kita hadapi. Bukan berarti seseorang tidak berpikir panjang atau keras. Intinya adalah filosofi yang tidak melampaui tim yang relatif kecil dengan pemahaman budaya bersama yang dapat ditampung dalam satu ruangan.

Jika seseorang ingin menulis alat berdasarkan "filosofi Unix", maka orang yang berbeda akan memiliki pendapat yang berbeda tentang apa arti "kesederhanaan" atau prinsip "melakukan satu hal" ⁵ bagaimana alat ini harus bekerja dengan benar - dan ketidakkonsistenan akan berkembang dalam warna yang subur, sebagai hasilnya Anda akan mendapatkan kompleksitas yang sangat besar, mirip dengan bahasa yang sangat tidak konsisten seperti PHP. Orang-orang mengolok-olok PHP dan JavaScript untuk berbagai keanehan dan ketidakkonsistenan, tetapi seperti bahasa dan pustaka standar, semua shell populer dengan koleksi alat * nix populer, secara bersama-sama, jauh lebih buruk dan mengandung lebih banyak kompleksitas acak karena inkonsistensi bahkan dalam distribusi Linux yang sama . Tidak mungkin sebaliknya. Jika Anda membandingkan distribusi Linux, BSD, Solaris, AIX, dll., Jumlah kerumitan acak yang harus diingat pengguna saat beralih sistem, menutupi ketidakkonsistenan PHP atau JavaScript.Bahasa pemrograman yang paling banyak diejek adalah contoh nyata dari desain hebat dibandingkan dengan mereka.

Untuk lebih jelasnya, saya tidak mengatakan bahwa saya sendiri atau orang lain dapat dengan lebih baik mengatasi perkembangan di tahun 70-an, dengan mempertimbangkan pengetahuan yang tersedia saat itu, dan menciptakan sistem yang akan berguna pada saat itu dan juga elegan hari ini. Tentu saja, mudah untuk melihat ke belakang dan menemukan masalah dalam retrospeksi. Saya hanya tidak setuju dengan komentar beberapa penikmat Unix, seperti McIlroy, yang mengisyaratkan bahwa kita telah lupa atau tidak memahami nilai kesederhanaan. Atau Ken Thompson, yang mengatakan bahwa bahasa C sama amannya dengan bahasa lainnya, dan jika kita tidak ingin kesalahan muncul, kita hanya perlu menulis kode tanpa kesalahan. Komentar semacam ini menyiratkan bahwa sedikit yang berubah selama bertahun-tahun. Diduga, pada tahun 70-an kami membangun sistem dengan cara yang sama seperti hari ini, dan selama lima dekade pengalaman kolektif, puluhan juta orang-tahun tidak mengajarkan apa pun kepada kami. Dan jika kita beralih ke asal-usul, ke pencipta Unix, maka semuanya akan baik-baik saja. Dengan segala hormat, saya tidak setuju.

Aplikasi: memori

Meskipun keluhan McIlroy tentang binari kembung agak di luar cakupan artikel ini, saya akan perhatikan bahwa pada tahun 2017 saya membeli Chromebook dengan RAM 16 GB seharga $ 300. Biner 1 megabyte bisa menjadi masalah serius pada 1979, ketika standar Apple II dilengkapi dengan memori 4 kilobyte. Apple II berharga $ 1.298 pada tahun 1979, atau $ 4.612 pada tahun 2020. Hari ini Anda dapat membeli Chromebook murah yang harganya kurang dari 1/15 dari harga ini, sementara itu memiliki memori empat juta kali lebih banyak. Keluhan bahwa penggunaan memori telah tumbuh ribuan kali tampak agak konyol ketika (portabel!) Mesin biaya urutan besarnya lebih murah dan memiliki memori empat juta kali lebih banyak.

Saya menyukai pengoptimalan, jadi saya mempersempit beranda saya menjadi dua paket (akan ada satu jika CDN mendukung brotli tingkat tinggi), tetapi ini adalah persyaratan estetika murni, saya melakukannya untuk bersenang-senang. Hambatan alat baris perintah tidak menggunakan memori, dan waktu untuk mengoptimalkan memori alat dengan ukuran satu megabyte sama dengan mengurangi halaman utama menjadi satu paket. Mungkin hobi yang menyenangkan, tapi tidak lebih.

Metodologi kompilasi tabel

Frekuensi penggunaan perintah diperoleh dari file publik dari sejarah perintah di github, itu tidak selalu sesuai dengan pengalaman pribadi Anda. Hanya perintah "sederhana" yang dihitung, tidak termasuk instance seperti curl, git, gcc (yang terakhir memiliki lebih dari 1000 opsi) dan wget. Konsep kesederhanaan adalah relatif. Perintah shell bawaan , seperti cd, juga tidak diperhitungkan.

Bendera berulang tidak dianggap sebagai opsi terpisah. Sebagai contoh, u git blame -C, git blame -C -Cdan git blame -C -C -Cperilaku yang berbeda, tetapi mereka semua akan dianggap sebagai satu argumen, meskipun -C -Cmereka -C sebenarnya adalah argumen yang berbeda.

Sub-opsi dalam tabel dihitung sebagai satu opsi. Misalnya, ini lsmendukung yang berikut:

--format=WORD across -x, commas -m, horizontal -x, long -l, single-column -1, verbose -l, vertical -C

Meskipun ada tujuh opsi format, ini dianggap sebagai satu opsi.

Opsi yang secara eksplisit ditunjukkan tidak berguna masih dianggap sebagai opsi, misalnya ls -g, yang diabaikan juga dipertimbangkan.

Beberapa versi dari opsi yang sama dianggap sebagai satu opsi. Misalnya, -Adan --almost-alluntuk ls.

Jika sertifikat mengatakan bahwa opsi itu ada, tetapi pada kenyataannya tidak ada, maka tidak diperhitungkan. Misalnya, bantuan untuk v7 mv mengatakan:

BAGS

Jika file1 dan file2 berada dalam sistem file yang berbeda, maka mv harus menyalin file dan menghapus yang asli. Dalam hal ini, nama pemilik menjadi nama proses penyalinan, dan koneksi apa pun dengan file lain terputus.

mv harus menerima flag -f sebagai rm untuk menekan pesan tentang keberadaan file target yang tidak dapat ditulis.

Tapi -fitu tidak dianggap sebagai bendera dalam tabel, karena opsi tersebut tidak benar-benar ada.

Tabel berakhir pada 2017 karena draf pertama artikel ini kemudian ditulis. Baru sekarang mereka membacanya.

Pada topik ini

Diskusi Mjd tentang filosofi Unix, dengan pemikiran tentang kekacauan / usr / bin / waktu versus waktu bawaan
Lelucon mjd tentang mendistribusikan opsi perintah pada tahun 1991
Dengan HN:
p1mrx:

Sungguh aneh ls telah berkembang menjadi 58 opsi, tetapi masih tidak dapat menampilkan nama file yang diakhiri dengan \ 0.

Sebagai latihan, cobalah mengurutkan direktori berdasarkan ukuran atau tanggal dan mentransfer hasilnya ke xargs, sambil mendukung semua nama file yang valid. Pada akhirnya, saya hanya menyerah dan memasukkan skrip mengabaikan semua file dengan \ n dalam namanya.

whelming_wave:

, (whitespace-in-filenames-safe). printf (od -> sed) , , , , , , . , sort --zero-terminated — GNU , macOS, , .
```
      printf '%b' $(
        find . -maxdepth 1 -exec sh -c '
          printf '\''%s %s\0'\'' "$(stat -f '\''%m'\'' "$1")" "$1"
        ' sh {} \; | \
        sort --zero-terminated | \
        od -v -b | \
        sed 's/^[^ ]*//
      s/ *$//
      s/  */ \\/g
      s/\\000/\\012/g')
```
zsh, , 'command', printf, zsh, escape- . , .

POSIX, , sort.
Unix
?

_{, , -, //.}

1. Kutipan ini sedikit berbeda dari versi umum karena saya menonton video aslinya . Sejauh yang saya tahu, semua salinan kutipan ini di Internet (Bing, DuckDuckGo dan indeks Google) diambil dari transkripsi yang sama dari satu orang. Ada ambiguitas tertentu, karena suaranya berkualitas buruk, dan saya mendengar kata-kata yang sedikit berbeda dari apa yang orang itu dengar. [mengembalikan]

2. Contoh lain tentang bagaimana kompleksitas diteruskan ke pengguna, karena tim yang berbeda menangani pemformatan secara berbeda, adalah pemformatan waktu . Waktu shell bawaan time, tentu saja, tidak kompatibel dengan /usr/bin/time. Pengguna harus mengetahui fakta ini dan tahu cara menanganinya. [mengembalikan]

3. Misalnya, untuk objek apa pun yang dapat Anda gunakan ConvertTo-Jsonatau ConvertTo-CSV. Atau "cmdlets" untuk mengubah tampilan properti objek . Anda dapat menulis memformat file konfigurasi yang menentukan metode pemformatan yang Anda inginkan.

Cara lain untuk melihat ini adalah melalui prisma hukum Conway . Jika kita memiliki seperangkat alat baris perintah yang dibuat oleh orang yang berbeda, seringkali dari organisasi yang berbeda, alat ini akan sangat tidak konsisten jika seseorang tidak dapat menentukan standar dan memaksa orang untuk menerimanya. Ini sebenarnya bekerja relatif baik di Windows, bukan hanya PowerShell.

Keluhan umum terhadap Microsoft adalah pergantian besar-besaran API, seringkali karena alasan organisasi non-teknis (misalnya, lihat tindakan Stephen Sinofsky seperti yang dijelaskan dalam tanggapan terhadap tweet jarak jauh ). Itu benar. Namun, dari sudut pandang pengguna yang naif, perangkat lunak Windows standar, sebagai aturan, mentransmisikan data non-tekstual jauh lebih baik daripada * nix. Cakupan data non-tekstual di Windows kembali ke setidaknya COM pada tahun 1999 (dan mungkin OLE dan DDE, dirilis masing-masing pada tahun 1990 dan 1987).

Misalnya, jika Anda menyalin dari Foo, yang mendukung format biner Adan Bdi Bar, yang mendukung format Bdan Ckemudian copy dari Bar ke Baz, yang mendukung CdanD, semuanya akan berfungsi dengan baik, bahkan jika Foo dan Baz tidak memiliki format yang didukung bersama.

Saat Anda memotong atau menyalin sesuatu, aplikasi pada dasarnya “memberi tahu” papan klip di mana format itu dapat menyediakan data. Ketika disisipkan ke dalam aplikasi, aplikasi akhir dapat meminta data dalam format apa pun yang tersedia. Jika data sudah ada di clipboard, Windows menyediakannya. Jika ini bukan masalahnya, Windows menerima data dari aplikasi sumber, dan kemudian mentransfernya ke aplikasi target, dan salinannya disimpan selama beberapa waktu. Jika Anda "memotong" dari Excel, ia akan mengatakan "Anda" bahwa ia memiliki data yang tersedia dalam banyak format. Sistem seperti itu cukup baik untuk kompatibilitas, meskipun tentu tidak bisa disebut sederhana atau minimalis.

Selain dukungan yang baik dari banyak format, sudah cukup lama bahwa banyak program mulai menangani dengan baik fitur-fitur ini, di Windows, di luar kotak biasanya ada dukungan clipboard yang baik.

Misalkan Anda menyalin dan menempelkan sejumlah kecil teks. Dalam kebanyakan kasus, tidak ada kejutan akan terjadi pada Windows atau Linux. Tapi sekarang seandainya Anda menyalin beberapa teks, tutup program dari mana Anda menyalin, dan kemudian menempelkannya. Banyak pengguna cenderung berpikir bahwa ketika menyalin data disimpan dalam clipboard, dan bukan dalam program dari mana data itu disalin. Di Windows, perangkat lunak biasanya ditulis sesuai dengan harapan ini (walaupun secara teknis pengguna clipboard API tidak boleh melakukan ini). Ini kurang umum di Linux dengan X, di mana model mental yang benar untuk sebagian besar program adalah bahwa menyalin menyimpan pointer ke data yang masih milik program dari mana ia disalin. Artinya, sisipan tidak akan berfungsi jika program ditutup.Ketika saya (secara informal) mewawancarai programmer, mereka biasanya terkejut dengan hal ini, kecuali mereka benar-benar bekerja dengan fungsi copy + paste untuk aplikasi mereka. Ketika saya mewawancarai non-programmer, mereka biasanya menemukan perilaku ini tidak hanya mengejutkan, tetapi juga membingungkan.

Kelemahan dari mentransfer clipboard ke OS adalah bahwa menyalin data dalam jumlah besar itu mahal. Misalkan Anda menyalin sejumlah besar teks, banyak gigabytes atau semacam objek kompleks, dan kemudian jangan menempelkannya. Bahkan, Anda tidak ingin menyalin data ini dari program Anda ke OS sehingga disimpan di sana dan tersedia. Windows melakukan ini dengan bijak: aplikasi hanya dapat menyediakan data sesuai permintaan , jika dianggap bermanfaat. Dalam kasus kami, ketika pengguna menutup program, ia dapat menentukan apakah akan meletakkan data di clipboard atau menghapusnya. Dalam hal ini, banyak program (misalnya, Excel) akan menawarkan untuk "menyimpan" data ke clipboard atau menghapusnya, yang cukup masuk akal.

Beberapa fitur ini dapat diimplementasikan di Linux. Contohnya,Spesifikasi ClipboardManager menjelaskan mekanisme penyimpanan, dan aplikasi GNOME biasanya mendukungnya (walaupun dengan beberapa bug ), tetapi situasi pada * nix benar-benar berbeda dari dukungan di mana-mana untuk aplikasi Windows, di mana clipboard yang kompeten biasanya diimplementasikan. [mengembalikan]

4. Contoh lain adalah alat di atas kompiler modern. Mari kita kembali dan melihat contoh Macilroy kanonik, di mana kompiler Unix yang tepat begitu terspesialisasi sehingga listing dilakukan oleh alat yang terpisah. Tetapi hari ini ini telah berubah, meskipun alat daftar terpisah tetap ada. Beberapa kompiler Linux populer memiliki ribuan opsi - dan mereka sangat kaya fitur. Sebagai contoh, salah satu dari banyak fungsi modern clang adalah analisis statis. Pada saat penulisan ini, ada 79 tes rutin analisis statis dan 44 tes eksperimental.. Jika ini adalah perintah terpisah, mereka masih akan bergantung pada infrastruktur kompiler dasar yang sama dan membebankan beban perawatan yang sama - sebenarnya tidak masuk akal untuk alat analisis statis ini untuk bekerja dengan teks biasa dan mendefinisikan kembali seluruh rantai alat kompiler yang diperlukan untuk mendapatkan titik di mana mereka dapat melakukan analisis statis. Mereka dapat berupa perintah terpisah alih-alih digabungkan menjadi dentang, tetapi mereka akan tetap bergantung pada mekanisme yang sama dan juga membebani pemeliharaan dan kompleksitas pada kompiler (yang seharusnya mendukung antarmuka yang stabil untuk alat yang bekerja di atasnya), atau mereka akan konstan istirahat.

Untuk melakukan segala hal dalam teks agar sederhana terdengar indah, tetapi sebenarnya representasi tekstual dari data seringkali bukan yang Anda butuhkan jika Anda ingin melakukan pekerjaan yang benar-benar bermanfaat.

Dentang yang sama hanya lebih fungsional daripada kompiler yang ada pada tahun 1979, atau bahkan semua kompiler yang ada pada tahun 1979 digabungkan, terlepas dari apakah itu dijalankan oleh perintah monolitik atau ribuan instruksi yang lebih kecil. Mudah untuk mengatakan bahwa pada tahun 1979 semuanya lebih sederhana dan bahwa kita, programmer modern, tersesat. Namun dalam kenyataannya sulit untuk menawarkan desain yang jauh lebih sederhana dan akan benar-benar diterima oleh semua orang. Tidak mungkin bahwa desain seperti itu dapat mempertahankan semua fungsionalitas dan konfigurasi yang ada dan sesederhana sesuatu dari tahun 1979. [mengembalikan]

5. Sejak awal, curl telah berubah dari mendukung tiga protokol menjadi 40. Apakah ini berarti bahwa ia "melakukan 40 hal", dan apakah filosofi Unix mengharuskannya untuk dibagi menjadi 40 perintah terpisah? Tergantung siapa yang bertanya. Jika setiap protokol adalah timnya sendiri, dibuat dan didukung oleh orang lain, kita akan memiliki kekacauan yang sama dengan tim-tim tersebut. Parameter baris perintah yang tidak konsisten, format output yang tidak konsisten, terlepas dari kenyataan bahwa semua ini adalah stream teks, dll. Apakah ini membawa kita lebih dekat ke kesederhanaan yang dianjurkan McIlroy? Tergantung siapa yang bertanya. [mengembalikan]

Komplikasi perintah konsol, 1979-2020

Aplikasi: memori

Metodologi kompilasi tabel

Pada topik ini

More articles: