Apakah Vim atau Emacs praktis untuk bahasa seperti .Net atau Java? [Tutup]


18

Jadi, saya terutama pengembang .Net yang melakukan beberapa hal di Java, Python dan beberapa lainnya dari waktu ke waktu. Saya telah mendengar banyak orang memuji Vim dan Emacs karena sangat meningkatkan efisiensi setelah dasar-dasarnya dipecahkan. Saya pasti bisa melihat berapa banyak fitur yang bisa sangat berguna dengan latihan yang cukup, dan bahkan percaya bahwa kurva pembelajaran mungkin sepadan dengan usaha. Namun ... tampaknya Anda benar-benar harus menjadi semacam penyihir makro dan hotkey agar seefisien Vim atau Emacs seperti rata-rata pengembang dalam Visual Studio, Netbeans, Eclipse, atau platform lainnya. Saya sudah mulai belajar menggunakan Vim dan berpikir beberapa fitur-fiturnya mengagumkan (misalnya mengedit kolom), tetapi tampaknya banyak alat yang disediakan oleh IDE berat tidak bisa diganti, beli bahkan teks yang paling dijus. editor.

  • menghasilkan file dbml untuk Linq-to-SQL
  • Pengujian otomatis
  • merancang UI
  • Membuat / mengatur proyek dan solusi

Saya tahu Vim dan Emacs dapat melakukan banyak hal yang sama dengan sangat kuat yang dapat VS lakukan (seperti intellisense, refactoring, dll.) Dan mungkin dapat melakukan beberapa atau semua contoh yang saya berikan, tetapi apakah realistis untuk mengatakan bahwa seseorang yang bekerja pada platform ini sebenarnya akan mendapat manfaat dari Vim atau Emacs?


2
Kami bekerja di Eclipse di toko saya, tetapi ada seorang pria di sini yang menggunakan Vim sebagai editor pimary dan Eclipse hanya untuk mengkompilasi dan jenis tugas manajemen kode.
Michael K

Jawaban:


14

Anda memiliki campuran konsep yang terjadi di sana, yang mungkin tidak mengejutkan karena VS menggabungkan banyak fitur yang berbeda secara bersamaan. Satu kutipan (dari situs ini) menunjukkan bahwa Emacs bukan IDE yang baik, Unix adalah IDE yang baik. Idenya adalah bahwa di dunia Linux / Unix, Anda mengandalkan beberapa alat khusus yang bermain bersama dengan baik daripada satu alat monolitik yang melakukan semuanya.

Sekarang, saya terutama memprogram dalam C #, dan saya menggunakan VS untuk melakukan itu. Saya juga sangat menyukai Emacs dan menggunakannya untuk hal-hal lainnya. Sekarang, seperti yang Anda katakan, apa yang dapat Anda lakukan di Emacs dan apa yang lebih baik dilakukan di Emacs berbeda. Tetapi dalam banyak kasus ini bukan pemetaan 1-ke-1 dan ada berbagai cara untuk mencapai tujuan yang sama menggunakan editor teks dan / atau alat lainnya.

Saya awalnya akan membahas masing-masing poin Anda, tetapi jawabannya selalu mengarah ke "ya, Anda bisa" dalam beberapa bentuk. Biasanya Anda akan bergantung pada: 1) alat luar (seperti perancang UI) untuk menghasilkan kode bagi Anda, mengimpornya; 2) dukungan otomatisasi dari dalam editor (seperti kode Elisp di Emacs) untuk mengotomatisasi tugas yang berulang; atau 3) Anda akan menyesuaikan diri dengan menggunakan alat berbasis teks alih-alih yang visual (seperti menggunakan MSBuild dan menulis file proyek Anda sendiri alih-alih mengandalkan pengaturan VS).

Di dunia Emacs, Anda tidak memiliki alat yang melakukan semuanya, Anda memiliki banyak alat dan kemampuan untuk menumbuhkan lebih banyak alat saat Anda membutuhkannya. Saya belum tahu cukup baik untuk melakukan semua itu, jadi saya menggunakan VS dan saya senang dengan alat yang memberi saya. VS adalah IDE yang sangat kuat, sangat bagus. Sekarang jika saya menggunakan Java, saya harus memperdebatkan alat mana yang akan saya gunakan karena saya tidak mengenal Eclipse atau IntelliJ dengan sangat baik. Untuk bahasa lain, Emacs cukup banyak menang karena itu akan melakukan lebih banyak bagi saya daripada editor teks lain atau IDE setengah jadi yang mungkin digunakan bahasa-bahasa itu. (Kecuali mungkin Smalltalk, tapi itu kasus unik.)


6

tetapi apakah realistis untuk mengatakan bahwa seseorang yang bekerja pada platform ini sebenarnya akan mendapat manfaat dari Vim atau Emacs?

Biarkan saya memberi Anda contoh saya: Saya bekerja pada sistem yang sebagian besar (tetapi tidak 100%) dikodekan dengan C #. Sistem tidak dapat dibangun dari Visual Studio - itu terlalu rumit. Oleh karena itu, saya tidak memiliki file sln (beberapa orang mencoba memelihara satu walaupun kami tidak membangun produk dengan itu, tetapi itu ternyata menjadi tugas yang mustahil) dan tidak memiliki manfaat dari intellisense, penelusuran kode, diagram kelas, dll. Alat yang berfungsi untuk saya adalah vim + ctags. Walaupun itu tidak sempurna (ctag mudah membingungkan), tetapi jauh lebih baik daripada menggunakan editor kode yang lebih rendah tanpa dukungan penelusuran kode.

Sekarang, saya mengerti bahwa sebagian besar pengembang .NET atau Java tidak dalam posisi yang sama seperti saya dan mereka mungkin lebih baik menggunakan IDE jika memiliki editor kode yang baik atau setidaknya add-in yang meningkatkan yang standar. Untuk Visual Studio ada add-on seperti VsVim yang dapat membuat pengalaman pengkodean lebih menyenangkan. Sama untuk Eclipse AFAIK.


3

Saya ragu ada banyak yang menggunakan VIM atau Emacs secara eksklusif lagi. Tapi saya belum menemukan pengembang yang tidak menggunakan editor teks (baik itu salah satu dari itu atau yang lain) karena IDE yang penuh sesak untuk beberapa hal, seringkali banyak hal.

Ingatlah bahwa pekerjaan Anda jauh lebih banyak daripada menulis kode Java, C #, atau C ++. Ada skrip ANT, makefile, file XML, file konfigurasi berbagai macam. Dan untuk banyak tugas kecil, waktu startup dari IDE itu mungkin terlalu lama. Eclipse dapat memakan waktu beberapa menit untuk memulai, VS serupa. Untuk dengan cepat mengubah sesuatu dalam satu sumber, atau hanya memeriksa sesuatu dalam file yang diketahui, itu terlalu lama. Memuat file dalam VIM hanya membutuhkan beberapa detik.


1
meskipun notepad ++ juga.
Raffael

tidak pernah menggunakan yang satu itu, tetapi memang pernah melihat orang lain menggunakannya (saya seorang VIM bujang :)).
jwenting

2

Saya menemukan bahwa menggunakan IDE dan vim (editor favorit pribadi saya) bukan konsep yang saling eksklusif. Ketika melakukan pengembangan .NET, saya biasanya mengatur kombo hot-key yang akan membuka file saat ini yang saya kerjakan di IDE dalam vim dan meletakkan kursor di tempat yang sama. Dengan cara ini jika saya ingin melakukan hal-hal yang hebat di vim, (seperti menggunakan makro, pengeditan vertikal, indentasi ulang, diffing, dll), maka saya menekan tombol kombo dan bang saya memiliki editor favorit saya, lakukan perubahan saya, simpan file dan keluar, dan kemudian saya kembali ke IDE lagi (Anda dapat mengaturnya sehingga file memuat ulang secara otomatis ketika sudah diedit di luar IDE di VS). Dengan cara ini saya mendapatkan yang terbaik dari kedua dunia.

Saya dulu menggunakan bahasa scripting untuk memanipulasi file teks dengan cara yang rumit. Setelah saya menemukan kekuatan menggunakan makro vim (dan beberapa fitur lainnya juga) saya menemukan bahwa saya dapat melakukan pengeditan / manipulasi semacam ini jauh lebih cepat dan efisien daripada yang saya bisa dengan bahasa scripting.

Sangat umum bagi saya untuk membuat satu skrip shell untuk melakukan beberapa hal rumit menggunakan vim, jalankan skrip shell yang saya buat dan kemudian buang.

2 sen saya :)


Ya, saya bermain-main dengan beberapa plugin untuk VS baik melompat saya ke emacs, menggunakan emacs sebagai "jendela editor kode", atau hanya menggunakan emacs keybindings. Belum mencintai semua itu. Makro untuk membuka emacs dan melompat ke tempat kursor yang sama terdengar seperti ide yang sangat keren. Saya mungkin harus mencobanya. Saya kebanyakan hanya menyalin-tempel di antara keduanya ketika saya perlu melakukan beberapa manipulasi teks yang berat.
CodexArcanum

0

Lihatlah proyek OpenIDE dan Continous Tests . Yang pertama berfokus pada menambahkan dukungan proyek .NET ke editor termasuk VIM dan Emacs. Yang lain adalah pelari tes kontinu mirip dengan AutoTest / ular sanca Sniffer / Autonose. Itu bisa dijalankan sebagai plugin VS atau mandiri.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.