Bagaimana perbedaan alur kerja programmer yang berorientasi CLI dari yang berorientasi GUI?

Saya telah mendengar banyak tentang keuntungan melakukan lebih sedikit pekerjaan pemrograman di aplikasi GUI dan menggunakan lebih banyak alat baris perintah (terutama yang berkaitan dengan menyelesaikan sesuatu dengan lebih efisien). Namun, karena saya tidak mengerti bagaimana alur kerja saya akan berbeda jika saya lebih bergantung pada alat-alat baris perintah, saya tidak dapat dengan mudah mengevaluasi apakah ada cukup hasil bagi saya secara pribadi untuk menginvestasikan waktu dan upaya mempelajari toolset baru dan mengubah alur kerja saya.

Sekarang juga:

• Saya mengkodekan beberapa proyek sampingan dalam bahasa seperti C / C ++ / D / C # / Java / Python menggunakan Visual Studio, Eclipse, dll., Dan menjalankannya dengan mengatur pengaturan build, dan menekan F5 untuk membangun / menjalankan.

• Saya sedang mengembangkan program web di tempat kerja, sehingga melibatkan penggunaan Django untuk mengatur server, terhubung ke database, dll ... hampir semua dalam editor teks SciTE.

• Untuk meluncurkan program reguler, saya menggunakan Launchy ... masih belum ada terminal. :)

• Untuk menyalin file dan yang lainnya, saya menggunakan find / move biasa dalam file manager grafis (Windows Explorer, Nautilus).

• Debugging: Saya menggunakan Visual Studio atau alat Debugging untuk Windows (jika saya menggunakan Windows). Saya belum melakukan banyak debug pada Linux, tetapi untuk hal-hal yang telah saya lakukan, saya telah menggunakan Eclipse (juga untuk Java pada Windows).

• Di tempat kerja: Untuk terhubung ke sistem build dan mengatur proyek, saya hanya menggunakan alat yang telah diintegrasikan ke dalam Eclipse untuk saya gunakan - tidak perlu untuk terminal atau apa pun (meskipun saya tentu saja dipersilakan untuk menggunakan terminal jika saya memang ingin)

Bagaimana rasanya melakukan hal-hal ini di CLI? Bagian mana yang menjadi lebih / kurang efisien? Aspek mana dari alur kerja saya yang perlu diubah untuk mendapatkan keuntungan terbesar dari perubahan menjadi bekerja sebagian besar di CLI? Dengan kata lain ... Jika Anda secara ajaib mengubah saya menjadi guru baris perintah, bagaimana alur kerja pengkodean baru saya akan berbeda dari cara saya saat ini, yang berpusat pada GUI, dalam melakukan sesuatu?

Saya tidak berpikir ini benar lagi. CLI memiliki keunggulan spesifik - jika Anda tahu sebelumnya apa yang Anda cari, maka Anda dapat mengetik lebih cepat daripada menavigasi ke dalam menu. Ini berarti bahwa jika Anda secara eksplisit ingin mengeluarkan perintah ke program yang memiliki sedikit konteks, maka sebagian besar lebih cepat. Namun, ada dua masalah.

Pertama, program GUI dapat menyimpulkan konteks untuk Anda. Misalnya, fitur Go To Definition dan Intellisense dari Visual Studio. Bagaimana Anda bisa meniru fitur-fitur itu dalam CLI?

Kedua, program GUI dapat menampilkan lebih banyak kepada Anda. Misalnya, Visual Studio Parallel Profiler, yang merupakan grafik penggunaan CPU di beberapa core dari waktu ke waktu. Bagaimana Anda bisa menampilkannya di CLI? Itu tidak masuk akal. Segera setelah data Anda diekspresikan lebih baik sebagai sesuatu selain teks, CLI langsung hilang. Contoh mudah lainnya adalah breakpoints. Di Visual Studio, Anda mengklik margin garis yang ingin Anda hancurkan. Apa yang akan Anda lakukan dalam CLI, coba cari file dan nomor baris dan masukkan perintah itu? Itu akan membawa Anda satu dekade relatif. Itu bahkan tidak termasuk beberapa inovasi GUI yang lebih baru, seperti Kanvas Debugger.

GUI mungkin lebih lambat jika Anda ingin menghabiskan waktu mendorong Debug berulang kali, tetapi begitu kasus penggunaan menjadi lebih kompleks, maka tidak mungkin CLI bisa mengikutinya.

Saya pikir perbedaan terbesar tidak terletak pada tugas individu tetapi pada dua hal:

Pertama dan terpenting, otomatisasi. CLI secara inheren skrip yang biasanya lebih sulit di Windows. Saya telah mendengar banyak hal membaik dengan PowerShell tetapi saya belum menggunakannya.

Kedua, filosofi UNIX tentang "pemisahan keprihatinan". Saya dapat menulis antarmuka berbasis readline kecil untuk sesuatu dan menggunakan emacs Mx shell menggunakannya di dalam emacs GUI. Ini membuatnya lebih mudah untuk memanfaatkan alat lain dan fungsi yang ada.

Untuk debugging gdb bekerja dengan baik tetapi saya biasanya lebih suka VS debugger. Ini mungkin perangkat lunak terbaik yang pernah dilakukan Microsoft.

Untuk membangun dan menjalankan sesuatu: buat. Atau bash. Di manapun.

Untuk pengembangan: emacs (konversi terbaru dari vi, oh malu!). Vi jika melakukan pekerjaan melalui ssh.

Saya benar-benar tidak bisa terbiasa dengan Eclipse. Saya pikir ini masalah "bentuk pikiran": itu tidak cocok untuk saya.

Bagi saya, beralih ke alur kerja CLI dari Visual Studio melibatkan menghafal banyak perintah * nix. Itu juga melibatkan beberapa sakit kepala setiap kali saya mengacaukan checkin SVN.

Tetapi perbedaan terbesar dalam alur kerja bagi saya adalah bahwa saya memperoleh pemahaman yang lebih baik tentang cara kerja sistem operasi . Dengan alur kerja GUI, itu hanya mengklik tombol dan menunggu program untuk merespons. Di dunia command-line, saya merasa seperti memberi tahu komputer secara langsung untuk melakukan sesuatu.

Dengan kata lain, alur kerja GUI adalah komputer yang berkomunikasi kembali kepada Anda, sedangkan alur kerja CLI lebih seperti Anda berkomunikasi langsung dengan komputer.

Satu tidak lebih baik dari yang lain, tetapi beralih dari lingkungan berbasis GUI ke terminal jelas merupakan suatu perjalanan.

Berikut adalah lebih banyak pengamatan dari seorang programmer yang telah hidup di kedua dunia. Saya tidak akan mengulangi poin yang sudah dibuat dalam jawaban lain:

Pengembangan berbasis CLI cenderung menggunakan berbagai program, yang masing-masing menjalankan 1 fungsi. Pengembangan berbasis GUI cenderung menggunakan 1 program besar (IDE), yang melakukan puluhan fungsi berbeda. Perbedaan ini memiliki beberapa konsekuensi:

Karena IDE dimaksudkan untuk menjadi "rumah" Anda di mana Anda bekerja sepanjang waktu, mereka mungkin menggunakan format (mungkin biner) milik untuk menyimpan data Anda. Kompatibilitas bukan masalah besar, karena mereka tidak mengharapkan Anda untuk bekerja di 2 IDE berbeda pada proyek yang sama. Alat CLI, di sisi lain, umumnya hanya bekerja dengan file teks biasa.

Dengan pengembangan berbasis CLI, Anda dapat secara bertahap beralih alat, atau mengintegrasikan alat baru ke dalam alur kerja Anda, lebih mudah. Memilih IDE lebih banyak atau tidak sama sekali, dan mengganti IDE Anda lebih menyakitkan.

Menggunakan skrip build CLI, dan bukannya menu "Build" bawaan IDE, menjadikannya lebih mungkin bahwa Anda dapat meninggalkan kode Anda selama beberapa tahun, kembali ke sana, dan membangunnya tanpa repot. Dengan pengembangan berbasis GUI, kemungkinan Anda menjalankan IDE yang sama sekali berbeda saat itu. Mungkin yang Anda gunakan ketika Anda menulis kode bahkan tidak berjalan pada OS Anda saat ini.

Dalam IDE, membangun alat Anda sendiri berarti mempelajari API plug-in (mungkin besar), dan mungkin menggunakan bahasa tertentu. Saat menggunakan CLI, tidak ada yang istimewa yang diperlukan untuk membuat alat khusus.

Di sisi lain, keuntungan dari suatu IDE adalah bahwa ia "baik" terintegrasi. Jadi Anda bisa mengklik di jendela editor Anda untuk mengatur breakpoint debugger, dan sebagainya.

Poin lain: pilihan Anda juga akan bergantung pada platform pengembangan, OS, dan bahasa yang Anda gunakan. Pada platform tertentu, pengembangan berbasis IDE sudah tertanam kuat dalam budaya pembangunan yang berlaku. Di negara lain, pengembangan berbasis CLI lazim. Jika Anda menggunakan platform di mana pengembangan berbasis IDE lazim, kemungkinan alat CLI akan kurang berkembang dan kurang didukung. Kebalikannya juga benar.

Sebagian besar masa kecil saya tidak dihabiskan di komputer karena kami bahkan memiliki internet di pertanian. Saya mulai pemrograman terlambat di sekolah menengah dan pada dasarnya bekerja di GUI sepanjang waktu. Di perguruan tinggi saya bertemu dengan seorang pria yang dibesarkan di CLI dan melakukan segalanya seperti itu. Jadi saya memutuskan untuk menyiapkan server linux daripada mendengarkan prof. Setelah beberapa tahun, teman saya memperhatikan saya menulis beberapa kode yang disematkan dan tidak percaya bagaimana saya menulis.

Saya pada dasarnya menggunakan setengah CLI setengah GUI. Ada beberapa hal yang dilakukan lingkungan GUI yang dibundel jauh lebih cepat dan lebih efisien. Dan hal yang sama berlaku untuk CLI. Sebagian besar pengeditan teks saya dilakukan di VIM sebagai editor CLI canggih VIM / EMACS (tolong jangan ada perang di sini) membuat manipulasi teks menjadi yang paling efisien. Hal-hal seperti Embedded debugging menggunakan GDB di sisi lain, sama menyakitkannya dengan mengedit teks tanpa keyboard. Tentu itu kuat dan yakin dengan waktu yang cukup Anda akan menemukan informasi yang Anda cari tetapi memiliki jendela GUI yang bagus dengan akses cepat ke blok memori apa pun sangat berharga terutama ketika mencoba membandingkannya dengan blok memori lain.

Bagaimanapun yang saya benar-benar coba katakan adalah bahwa itu tidak boleh GUI vs CLI melainkan apa yang CLI lebih baik dan apa yang lebih baik di GUI. Karena pada akhirnya jika IO Anda lebih lambat dari proses berpikir Anda ada masalah.

"dikonversi menjadi guru CLI dalam semalam?" Aye, ini masalahnya. GUI yang dirancang dengan baik cenderung lebih mudah ditemukan daripada CLI, dan lebih mudah memaafkan bagi pemula.

Alur kerja saya, baru-baru ini ditingkatkan oleh manajer jendela ubin (DWM), terdiri dari banyak mengetik. Laptop saya sekarang benar-benar dapat digunakan tanpa mencolokkan mouse (Trackpad memadai untuk apa yang tersisa dari menunjuk). Saya menjaga banyak aplikasi tetap terbuka dan beralih dengan alt-tab. Saya tidak membuang waktu untuk memindahkan dan mengubah ukuran jendela.

Sebagian besar waktu, saya menggunakan browser, vim, dan banyak terminal. SSH memberi saya banyak fleksibilitas untuk tempat saya bekerja (secara fisik). Remote desktop mungkin menawarkan pengalaman yang lebih baik ketika kita semua memiliki pipa 10Gigabit ke internet, tetapi saya tidak akan menahan nafas.

Saya belum belajar vim dengan cukup baik untuk mengambil keuntungan dari fitur-fiturnya yang kompleks, tetapi saya condong ke arah itu - saya ingin vim melompat ke garis kanan # setelah gagal menghasilkan. (Secara teknis vim adalah Antarmuka Visual, meskipun berjalan di terminal, tapi saya mengendarainya dengan keyboard, bukan mouse.)

Masalah sebenarnya adalah antarmuka yang dirancang dengan buruk . Antarmuka yang dirancang dengan baik sulit dibuat, sehingga tidak sering terjadi di kedua kubu. Tetapi karena lebih banyak non-ux-penyihir merancang GUI hari ini daripada CLI, ....

(Kencing hewan peliharaan besar saya yang lain adalah mengasapi. Ketika dibutuhkan program 19MB untuk membantu saya menyelesaikan tugas yang sama dengan program 200kB, ada sesuatu yang salah. XTree Gold untuk DOS meningkatkan produktivitas saya lebih dari manajer file modern. Windows 2.11 hanya menggunakan ubin windows. Turbo C adalah IDE yang mengagumkan. Mengapa Nook saya tampaknya berjalan lebih lambat daripada Mac klasik? Mengapa kernel saja sekarang mengambil lebih banyak ruang disk daripada seluruh sistem yang digunakan untuk mengambil?)

Dengan antarmuka pengguna grafis, Anda dipaksa untuk berinteraksi dengan program berulang kali untuk melakukan operasi yang sama berulang-ulang. Dengan sebuah shell, Anda dapat mengotomatiskan hal-hal dengan lebih mudah, dan membuat program bekerja bersama melalui perpipaan - yang misalnya dapat digunakan untuk menampilkan kecocokan ke ekspresi reguler dalam satu set file atau paket jaringan. Seperti yang dikatakan, lebih cepat untuk banyak operasi.

Pemrograman di terminal mungkin tidak jauh lebih baik daripada di editor grafis, kecuali Anda menggunakan SSH.

Saya pribadi menemukan shell unix jauh lebih mudah didekati daripada baris perintah Windows biasa, dan sekarang saya sangat terbenam di dalamnya pada sistem Linux dengan manajer jendela ubin dan banyak terminal.

Semua contoh Anda adalah proses satu langkah. Di sebagian besar lingkungan GUI, jika Anda ingin memindahkan file yang tidak ada hubungannya dengan aplikasi saat ini, Anda dapat melakukannya jika dari menu file tanpa meninggalkan aplikasi. Tidak masuk akal pergi ke command prompt. Jika Anda ingin menyalin file dan memberinya nama yang berbeda, pada command-line Anda bisa melakukan ini sekaligus. Untuk meletakkan ini dalam file batch, Anda setidaknya perlu tahu bagaimana melakukan ini, tetapi Anda kemudian dapat menjalankan file batch dari GUI jika Anda mau.

Saya memiliki perdebatan serupa tentang perintah keyboard v. Mouse.

Cara saya bekerja memihak GUI sejauh ini.

Penggunaan umum:

• Tiga IDE untuk tiga platform berbeda. Juga jendela Notepad ++ untuk beberapa skrip. Tidak mungkin saya bisa mengingat perintah untuk semua sistem yang dibangun itu. Masalah dengan CLI adalah Anda perlu mengetahui banyak detail hanya untuk membangun sebuah pekerjaan. IDES modern biasanya memiliki beberapa opsi yang sesuai di sana secara default. Anda selalu dapat melihat lebih dekat ketika saatnya tiba.
• SVN atau Git terintegrasi. Ada begitu banyak pilihan untuk program yang merupakan tambahan untuk pemrograman, dan sebagian besar waktu saya hanya melakukan komit atau memperbarui.
• Hal-hal jaringan: Beruntung saya, saya bisa melakukan semua pengaturan jaringan di kantor kami juga. Sebagian besar papan jaringan akan memberi Anda banyak perintah CLI, tetapi jika ada satu hal di mana Anda memerlukan ikhtisar keadaan, itu firewall dan perutean. Untuk perutean saya bisa langsung dengan baris perintah, tetapi firewall menjadi rumit, dan jika ada satu hal GUI yang baik dalam hal itu menampilkan banyak info.
• Secara umum ada banyak perpindahan dari satu hal ke hal lainnya. Sakelar konteks lebih mudah dengan konteks visual.

Adapun manfaat utama CLI, scripting, saya hampir tidak pernah melakukan itu. Tugas berulang yang kita miliki hanyalah aplikasi pekerjaan cron yang telah kita lempar bersama dalam c # dan tidak sering diubah. Kami memang memiliki cara untuk membuat berbagai hal berjalan di Linux, tetapi terutama porting (boost), sehingga mengacaukan file dan hal-hal seperti itu diminimalkan. Dan jika semuanya menjadi berbulu, ada IDE yang bagus untuk Linux juga.