Ogni volta che cerchi un editor di testo, indipendentemente dalla lingua che stai utilizzando, vi e Emacs sono hall-of-famers.
Tuttavia sono antichi e abbiamo alternative migliori (almeno spero che lo facciamo).
Perché gli sviluppatori sono bloccati su questi due editor? Non dovremmo lasciarli e cercare di inventare o cercare qualcosa di nuovo?
(Ho pieno rispetto per Emacs e i fan di vi).
I motivi principali per cui preferisco un editor basato su terminale su un IDE completo:
ssh su qualunque computer devo essere acceso, avviare Vim e iniziare a lavorare. In base alla quotidianità, utilizzando la sessione screen e Vim consente un facile accesso da qualsiasi posizione. Gli IDE sono entusiasti di lanciare lezioni all'interno del tuo progetto, ma per me la mia produttività è maggiore di ordini di grandezza con Vim.
I programmatori sono noti per l'utilizzo degli strumenti che li aiutano a svolgere il lavoro nel modo più efficiente possibile. Questi editor sono antichi ma ancora in uso perché sono buoni, solidi editori, comprovati dal tempo. Se riescono a portare a termine il lavoro e a fare il lavoro bene , perché dovremmo lasciarli a favore di qualcos'altro?
Supponi che non si evolvano. Emacs continua a crescere a passi da gigante; e, mentre vi stava diventando un po 'monotono, Vim lo ha ringiovanito e semmai sta crescendo (in termini di funzionalità almeno) più veloce di Emacs.
Ma quando si tratta di ciò, è ciò che si lavora meglio con quello che conta. Se sei più produttivo in Eclipse, più potenza per te. Lo stesso se preferisci Vim.
Molti (la maggior parte?) dei migliori programmatori che conosco disprezzano gli IDE e fanno affidamento esclusivamente su Emacs. Io non sono così irriducibile, e uso sia Eclipse che Emacs, ma ci sono un paio di motivi per cui preferisco usare Emacs:
Esperienza coerente con QUALSIASI linguaggio - Il supporto in Eclipse per alcuni dei linguaggi più recenti (Scala, Clojure, ecc.) è incoerente nella migliore delle ipotesi e nel peggiore dei casi è subparto. Gli autori dei plugin sono al lavoro per migliorare l'esperienza, ma spesso mi imbatto in piccole cose che mi sembrano strane. Certo, puoi sempre passare a un altro IDE che ha un supporto migliore per quella particolare lingua, ma ora ti stai divertendo con gli IDE. Non mi sono mai sentito in questo modo mentre lavoravo in Emacs.
Non mi piace la magia "IDE" . Gli IDE tendono a fare molte cose automaticamente in nome della convenienza. È grandioso ... finché qualcosa non si rompe. Quindi può essere un processo frustrante o addirittura esasperante per rimettere le cose a posto.
Ho iniziato a giocare con l'idea di passare a redcar editor . È estensibile come Emacs, ma al posto di Emacs Lisp usi JRuby . È leggero, e sicuramente non è un IDE in piena regola. Se ti trovi in TextMate , è compatibile con i bundle di TextMate, ma ha i vantaggi di essere libero e open source. Sicuramente uno strumento da verificare, soprattutto per gli sviluppatori di Ruby.
shouldn't we drop them and trying to invent or looking for something new?
tl; dr: molte persone non vogliono imparare un nuovo editor
La risposta completa:
A UNIX wizard hears cries of torment from his apprentice's computer room where the apprentice is studying, and goes to investigate.
He finds the apprentice in obvious distress, nearly on the verge of tears. "What's the problem?" he asks. "Why did you cry out?"
"It's terrible using this system. I must use four editors each day to get my studies done, because not one of them does everything."
The wizard nods sagely, and asks, "And what would you propose that will solve this obvious dilemma?"
The student thinks carefully for several minutes, and his face then lights up in delight. Excitedly, he says, "Well, it's obvious. I will write the best editor ever. It will do everything that the existing four editors do, but do their jobs better, and faster. And because of my new editor, the world will be a better place."
The wizard quickly raises his hand and smacks the apprentice on the side of his head. The wizard is old and frail, and the apprentice isn't physically hurt, but is shocked by what has happened. He turns his head to face the wizard. "What have I done wrong?" he asks.
"Fool!" says the wizard. "Do you think I want to learn yet another editor?"
Immediately, the apprentice is enlightened. http://neugierig.org/content/unix/
Penso che gli IDE (Visual Studio, Eclipse, IntelliJ) siano adatti a risolvere un'altra classe di problemi rispetto a quelli che risolvi con emacs / Vim.
Quando hai una grande piattaforma su cui programmare, con molte librerie e un'alta integrazione tra tutti gli elementi (suoni come Microsoft), un IDE dimostrerà che vale la pena. Alcuni si riferiscono a questo come "attaccare le librerie insieme" e non suppongono che sia "codice reale". Ti aiuterà molto quando rileverai gli errori in anticipo (in un certo modo anche Emacs non può).
Quando sviluppi applicazioni per l'utente finale (per esempio) per Android, puoi farlo effettivamente senza Eclipse. Tuttavia, con tutti i tipi di file che devono essere aggiunti prima della distribuzione, Eclipse ti aiuterà molto automatizzando queste attività per te.
Quindi se sei uno sviluppatore di applicazioni che lavora su una sola piattaforma con molte librerie (sviluppando applicazioni di classe Enterprise in Java EE, .NET ecc.) un IDE sarà un "miglioramento" nel tuo flusso di lavoro. Tuttavia, non appena si deve lavorare regolarmente in un ambiente terminale (per esempio sui server Unix) o si utilizzano molte lingue diverse, nessun IDE può misurare rispetto alle qualità Vim / emacs.
Un'ultima cosa è che lavorare con Vim / emacs ti costringe a capire almeno un po 'di piattaforma / linguaggio prima di usarlo. Molti IDE ti consentono di operare in una lingua senza sapere cosa sta succedendo; quindi usare Vim / emacs ti costringerà a ottenere alcune informazioni su ciò che stai realmente facendo.
Nel corso di circa 40 anni di informatica, come studente e professionista, ho usato almeno quindici (15) diversi editor ed IDE. Di tutti loro, emacs era di gran lunga il migliore, allora e ora.
In primo luogo, passo troppo tempo a rimbalzare tra più file e più posti all'interno di singoli file per avere una buona esperienza con qualsiasi editor che si rifiuta di farmi vedere più di un file alla volta, o più di due alla volta. Emacs è l'unico editor o IDE che ho visto che mi consente di vedere tutto ciò di cui ho bisogno in una volta. (Alcuni anni fa, mentre esploravo un sistema legacy, di solito avevo otto (8) riquadri aperti in una finestra di emacs.Ancora oggi, ho regolarmente tre o quattro riquadri aperti, ea volte avrò due o tre invocazioni di emacs aperte, perché ho bisogno di più shell e ho bisogno di copiare e incollare i risultati tra di loro.)
In secondo luogo, sono ancora solo umano e occasionalmente commetto errori. Ogni altro editore che abbia mai usato era perfettamente felice di lasciarmi sparare il piede, SENZA AVVERTIMENTO, senza alcuna possibilità di riprendermi, lasciandomi voler commettere ingiustamente atti vili e violenti contro l'autore di detto GDPOS. (Quelli che mi hanno procurato non erano QUI quanto il coccio che quasi ha fatto linciare Charles Simonyi mentre era allo Xerox PARC, prima di andare in Microsoft e ha inflitto notazione ungherese al mondo - un atto per il quale il linciaggio è troppo morbido una punizione.) Emacs non mi ha mai fatto questo; non ha mai distrutto irrevocabilmente nulla senza darmi un grande avvertimento. Quando ero ancora nuovo a Emacs, occasionalmente facevo "Cosa è appena successo?", E ho sempre immaginato cosa avevo fatto in pochi secondi, e sapevo come ripararlo altrettanto rapidamente.
Non esiste un editore che in realtà ENHANCES produttività. Il meglio che puoi ottenere è il minimo degrado della produttività. La metrica, per me, è "Quanto male questa cosa mi rallenta?" Rispetto a emacs, sul genere di cose che faccio normalmente, tutto il resto è molto peggio.
La mia SOLO lamentela con emacs era che non era disponibile per Oberon, quando giocavo con Oberon qualche anno fa.
Sono un utente Vim.
Devo usare gli IDE a causa dei progetti a cui sto lavorando, a volte non puoi eluderli. Sono abbastanza abile nell'usare Code :: Blocks e Eclipse , tuttavia, quando possibile, mi piace l'interfaccia utente di detti IDE per funzionare come quella di Vim.
Ho la mia combinazione di colori per Vim e voglio gli editor di testo di altri IDE per funzionare esattamente allo stesso modo.
Mi piacerebbe un IDE, manca l'editor di testo e dove posso collegare l'editor che voglio. Non sarebbe bello, se potessi inserire il mio Vim standard in Emacs o Code :: Blocks, ma avendo il resto dell'IDE attorno ad esso?
In qualche modo è sfuggito alla portata degli sviluppatori di IDE, ma lo desidero segretamente quasi sempre, quando o sto usando solo Vim e Makefile per progetti più grandi, o un IDE e il suo ingombrante editor di testo.
Il mio IDE di scelta è Linux. Diamine, può eseguire altri IDE, servire siti web, eseguire programmi in una varietà di lingue e combinando cose (la pipe) può eseguire programmi che sono stati scritti in lingue diverse come se fossero una. Quella cosa è fantastica. Oh, e può connettersi a Internet e fare ogni sorta di cose interessanti anche con esso, tra cui generare altre versioni di se stesso. Coolio!
Non accontentarti di un IDE quando hai già Linux.
A parte un po 'di BASIC da bambino, ho imparato a programmare su Unix. La filosofia di Unix è di avere molti strumenti più piccoli che interagiscono, ma che si concentrano sul fare un solo lavoro e farlo bene. Quindi, mi sembra naturale avere un software separato per la modifica, la compilazione, il controllo del codice sorgente e il debug. È interessante notare che gli IDE sono "integrati", ma non è possibile adattare tutte le funzionalità in un'unica finestra contemporaneamente, quindi ci si imbatte in cose come le prospettive, in cui sostanzialmente si cambiano le modalità tra quelle diverse attività, anche se con qualche sovrapposizione .
Potrei capovolgerlo e chiedere perché la gente tollera modifiche dolorosamente lente e non vim. Il modo migliore in cui posso descrivere la sensazione di guardare qualcuno modificare il codice in questo modo è come quando ti trovi bloccato dietro un'auto che va a 10 mph troppo lento perché è al telefono, o come guardare un dattilografo relativamente veloce a caccia e becco . Stanno andando abbastanza veloci per portare a termine il lavoro, ma allo stesso tempo sono abbastanza lenti da far impazzire.
Molte persone dicono che trascorrono la maggior parte del tempo a pensare comunque, quindi un montaggio un po 'più veloce non fa molta differenza. In tal caso, la digitazione è un'interruzione e alcuni secondi di modifica in più possono fare la differenza tra mantenere il treno di pensieri o doverlo riprendere. Inoltre, se sei un dattilografo di lunga data, sai che le tue dita digitano parole comuni senza che tu nemmeno pensi coscientemente quali tasti colpire. Quando sei un utente Vim da lungo tempo, questo tipo di fluidità si manifesta per cose come le linee mobili e le parole. Nel tempo necessario per dire "cancella" in "cancella quelle 2 righe" le mie dita l'hanno già fatto e la mia concentrazione è completamente ininterrotta.
Vim è anche estremamente personalizzabile e i plugin installati e vimrc si evolvono man mano che il tuo lavoro si evolve. Quando qualcosa inizia a intralciarti, cerchi un modo migliore per farlo e incorporalo nella tua configurazione o nei comandi più usati. Ho imparato vi nel 1993 e continuo a fare personalizzazioni quando i miei bisogni cambiano. Proprio questa settimana ho modificato il completamento del mio nome di tabulazione per funzionare più come bash, perché il mio flusso di lavoro è cambiato per fare molto di più di recente e il comportamento predefinito mi dava sui nervi.
Inoltre, non sono d'accordo sul fatto che non valga il tempo di imparare. Ci è voluto molto più tempo per imparare a toccare il tipo piuttosto che sentirsi produttivo in vi, per un simile aumento della velocità di modifica del codice, ma non si vedono i programmatori lamentarsi di quanto tempo ci è voluto per imparare a toccare il tipo. E puoi imparare alla tua velocità e aggiungere nuovi comandi al tuo repertorio come hai la tendenza. Se inizi con set im nel tuo vimrc (sta per insertmode, ma lo chiamo affettuosamente idiotmode per quando un collega ha bisogno di scrivere alla mia scrivania), potresti anche non realizzare che stai usando vim!
Uso Emacs come mio editor principale. Gli unici altri editor che abbia mai considerato seriamente erano vim e TextMate. Gli IDE (e ne ho provati alcuni tra cui Eclipse) non avevano le funzionalità di cui avevo bisogno.
In realtà ho avuto questa conversazione con un mio collega non molto tempo fa. Mi stava dicendo quanto l'IDE sia migliore mentre usava il suo mouse per fare clic su un gruppo di pulsanti e menu. Questo mi ha fatto ridere.
Proverò qualsiasi editor con le seguenti funzionalità (tutte fondamentali per il modo in cui sviluppo).
Tendo anche a fare meta-programmazione che spesso rende inutili gli strumenti di auto-refactoring; l'unica area in cui ritengo che gli IDE siano bravi.
Sono stati inventati altri redattori con un patrimonio (e controversie) altrettanto ricco, e forse è solo questione di tempo prima di passare dagli strumenti scritti per la prima volta negli anni '70 (vi / Emacs) a uno degli anni '80 ( Sam ) o anche uno degli anni '90 ( Acme ).
"Sam è l'editor di testo preferito di molti eminenti scienziati informatici, ha sostituito ed come Ken Thompson editor di testo preferito, e lo usa ancora oggi Sam è l'editor di testo usato da Bjarne Stroustrup e Brian Kernighan, altri invece, come Dennis Ritchie, sono passati a utilizzare Acme. " Ecco l' articolo di Sam da Wikipedia.
Ma cosa so, sto ancora usando Vim.
Sono l'unica persona che usa ancora ed occasionalmente?
(E per coloro che pensano che il codice sia rilevante ...
$ size /bin/ed
text data bss dec hex filename
42160 2300 0 44460 adac /bin/ed
$ size /bin/vi
text data bss dec hex filename
692378 27796 13884 734058 b336a /bin/vi
$ size /usr/bin/emacs
text data bss dec hex filename
2033257 4692020 0 6725277 669e9d /usr/bin/emacs
)
Un altro vantaggio di ed è che puoi eseguirlo su un teletype ... o il più stupido dei terminali stupidi.
"Migliore" è una parola soggettiva. Se sono felice e produttivo usando un editor di testi, chi è X o Y o Z per dire "rilascia e usa qualcos'altro"? Se si tratta di una politica aziendale o qualcosa che lo rende impossibile, tuttavia non abbiamo altra scelta.
Suppongo di essere un'anatra strana, ma in realtà uso editor diversi, a seconda della situazione.
Vim :
Quando sono connesso (ssh'd) su un server remoto (ad esempio guardando i log) e voglio modificare rapidamente un file e apportare qualche modifica. Molto più veloce della navigazione nella stessa cartella (SAN ospitata) dal mio desktop locale.
Notepad ++ :
Informazioni sulla stessa situazione: per una modifica rapida, ma questa volta quando non voglio aspettare che Eclipse (IDE aziendale) venga caricato.
Eclipse :
È l'IDE aziendale in cui lavoro. Abbiamo alcuni plugin interni per poter avviare direttamente la build da Eclipse su una macchina remota ... e soprattutto un plugin per individuare le librerie prodotte da altri team e con cui stiamo lavorando (e replicare le intestazioni in locale per indicizzazione rapida). Dal momento che sto parlando di migliaia di librerie ... è davvero utile;)
OpenGrok / Doxygen :
Più codice di navigazione rispetto all'edizione corretta, ma comunque molto utile! Il mio browser è configurato per navigare, quindi è utile qui.
In conclusione: tendo ad usare qualsiasi editor che mi consenta di svolgere il compito con relativa facilità e velocità decente.
Preferisco mangiare le mie mani piuttosto che usare uno di loro. Ho adorato Visual Studio mentre stavo facendo C ++. Eclipse è meh. IntelliJ IDEA è eccellente. Mi piaceva anche JBuilder , ma non l'ho usato da anni.
A volte lavorerò su sistemi prevalentemente nudi, dove l'unico editor installato è vi. Per casi come questi, aiuta davvero a conoscere almeno i comandi di base di Vi.
vi ed emacs sono anche molto estendibili, tanto che possono effettivamente essere IDE funzionanti con la giusta quantità di plugin. Per me, posso modificare i file molto più velocemente in vi, in quanto non devo togliere le mani dalla tastiera per muovere un mouse. Ha anche caratteristiche che non ho visto in alcuni IDE (anche se ammetto che non ho visto molto), come essere in grado di modificare colonne di testo, memorizzare più parole "taglia" in più buffer per incollare, ecc.
Gli editori impiegano del tempo per imparare, ma sono anche molto potenti. E sì, non sono per tutti.
Una lettura interessante in qualche modo correlata è Perché dovrei usare un IDE?
Mi attengo a vi perché è stato il primo editor che ho imparato a scuola ed è quello con cui sono più produttivo oggi. Lavoro con molte varianti UNIX ed è disponibile su tutti (e funziona allo stesso modo indipendentemente dall'ambiente). Fa quello che mi serve, quindi perché cambiare per il gusto di cambiare.
Uso un IDE per il mio lavoro java (ora Intellij Idea), ma trascorro molto del mio tempo usando vi.
Ci sono alternative migliori? Proprio l'altro giorno avevo una lista di nomi di schemi che dovevo ridurre (grazie, Oracle!). Almeno metà di essi è terminato con la parola "Test". Ho deciso di eliminare il "Test" dalla fine e prefisso il nome con "T". In vi, questa era una semplice regex di ricerca e sostituzione, ci sono editori recenti che possono farlo?
In questo momento, mi sto ritrovando a lavorare per metà del tempo, nano , semplicemente perché è lo strumento che si adatta al lavoro - modifica di piccoli script sulla riga di comando su ssh. L'uso di Eclipse sarebbe come un cameriere che usa un robot da cucina a forma di taglia-da-taglia-taglia-tritare turbo e frullato per macinare il pepe sulla mia insalata.
Leggi altre domande sui tag ide text-editor emacs vi