Emacs / Vim / Vi - hanno un posto nel moderno ecosistema di sviluppo software? [chiuso]

La cosa interessante di Vim ed Emacs non è semplicemente la velocità con cui puoi lavorare. È il semplice fatto che Vim ed Emacs ti consentono di modificare il tuo testo quasi alla velocità con cui pensi di apportare le modifiche. Poiché non hai bisogno di effettuare selezioni, passare al mouse o dare la caccia ai menu, la tua mente è libera di concentrarti su ciò che è importante mentre modifichi: il tuo codice.

Questo vuol dire che quando scrivi il codice, c'è solo una cosa a cui vuoi pensare: cosa deve fare il tuo codice e come deve farlo. Ogni volta che ti fermi per apportare modifiche al codice che hai scritto, si tratta di un'interruzione; sei costretto a non pensare a cosa sta facendo il tuo codice ma a come apportare le modifiche necessarie. Quindi, invece di tornare indietro e fare una selezione visiva e cambiare la mia modalità di pensiero, dalla scrittura del codice all'editing di testo, Vim ed Emacs mi permettono di eseguire la modifica e di farla con essa, senza dover spendere più energia mentale sul compito di apportare il cambiamento.

E quando togli la mano dalla tastiera per afferrare il mouse, è un altro tipo di interruttore di contesto: non stai più pensando al codice, ma al testo che puoi vedere sullo schermo e agli elementi visivi che circondano la tua area di modifica. Quindi, devi tornare al codice di scrittura, mentre la tua mano cerca le chiavi di casa. Con Vim o Emacs, questo interruttore di contesto non deve mai essere fatto e la tua mente non ha mai bisogno di lasciare il compito a portata di mano: quello di scrivere il codice.

Un sacco di persone, me compreso, usano Vim o Emacs come strumenti preferiti perché sono liberatori nel senso che passi meno tempo a pensare al montaggio e più a quali modifiche stai apportando. Perché, in realtà, cosa è la programmazione, ma linee di testo giocoleria?

Plugins and extensions? I bet nothing comes close to R# or IDEA in terms of refactoring support [...]

Esistono questi tipi di strumenti. Suggerimenti e metodi abbondano. L'unico limite a Vim ed Emacs è che il loro scopo principale è la modifica del testo. Ma questo non impedisce a nessuno di trasformarlo in un ombrello sotto il quale è stato costruito l'intero IDE.

Penso che la fonte della tua costernazione sia che scegli di non vedere il valore in Vim ed Emacs. Va bene. Non ho intenzione di provare a convertirti.

Ma dirò che dopo aver provato ogni editor di testo e IDE che ho incontrato, torno ancora a Vim. Mi sento a mio agio, sono contento degli strumenti che mi fornisce e il mio desktop Linux soddisfa ogni mia esigenza come IDE, tutto nella finestra del terminale. Mi ha reso dipendente dalla peculiare struttura di comando di Vim, ma poiché Vim corre ovunque, non è mai stato un ostacolo; solo un vantaggio.

Due punti. Innanzitutto, non è la velocità di scrittura che fa la differenza, è la latenza. In altre parole, il tempo trascorso tra quando hai deciso di fare una modifica e quando hai terminato di fare la modifica e di tornare a pensare al problema. Un paio di secondi possono fare la differenza tra perdere il filo del pensiero o no.

Prendi qualcosa di semplice come scambiare due righe di codice, per esempio. Un utente esperto di Vim può farlo essenzialmente dalla memoria muscolare con d d p . Usi più capacità mentale di quanto sia evidente quando devi manovrare con precisione un mouse, assicurati che tutto ciò che desideri sia selezionato, premi ctrl x , freccia su, ctrl v , quindi assicurati di aver incluso l'interruzione di riga e che tutto sia ancora rientrato correttamente. È come mandare sms e guidare. Pensi di prestare maggiore attenzione alla strada di quanto tu non sia davvero. Preferisco che tenga d'occhio il problema.

In secondo luogo, nulla impedisce a un utente vim di utilizzare un IDE quando gli si addice. C'è una ragione per cui quasi ogni IDE ha un'opzione per specificare un editor personalizzato. Uso abbastanza frequentemente un IDE per navigare e fare il debug, e vim per il montaggio.

La linea di comando linux è l'ambiente di sviluppo integrato ultimate ; vim ed emacs si interfacciano perfettamente con la toolbox unix per creare un ambiente di sviluppo ottimizzato che non ha davvero eguali.

I bet nothing comes close to R# or IDEA in terms of refactoring support ("Rename" refactoring implemented by means of "Search and Replace" is not a refactoring IMO); others are trivial.

Non tutto il codice è tipicamente scritto in modo statico o in una lingua che consente un buon supporto per gli strumenti (refactoring, find references, auto-complete, ecc.). Questi editor hanno ancora forti argomenti per loro quando lavorano con queste lingue.

Funzionano bene anche con script di compilazione, file di configurazione, file di registro e altri frammenti di shrapnel che devono essere costruiti / analizzati / grep'd / coddled / ottimizzati (spesso solo CLI) * ambienti nix, che costituiscono ancora un porzione considerevole di piattaforme di codice di produzione.

Do said editors have a justified place in a modern software development ecosystem?

Sì.

1) Se non c'è un buon IDE per il linguaggio di programmazione con cui lavori (che è la maggior parte di loro, davvero).

2) Se l'IDE non può gestire la dimensione del tuo progetto.

3) Per varie attività quando si desidera modificare rapidamente un file di testo senza attendere l'apertura e l'inizializzazione di un IDE.

Il supporto Intellisense / refactoring è davvero l'unica funzionalità interessante per gli IDE oggi. Mi aspetto che in futuro vengano create librerie collegabili per fornire intellisense / refactoring per varie lingue, in modo che uno possa avere lo stesso livello di supporto linguistico in Emacs / Vim come negli IDE. (Per alcuni linguaggi esistono già tali librerie). Se ciò accade, Emacs / Vim sarà lo strumento di sviluppo preferito per un certo numero di sviluppatori, poiché forniscono un'esperienza diversa rispetto a un IDE (più snella, più veloce, più semplice, ecc.). / p>     

Personalmente ritengo che la codifica in vim abbia aiutato la mia capacità di codifica, più o meno nello stesso modo in cui imparare a gestire correttamente memoria e puntatori in C o ad imparare linguaggi funzionali come Haskell mi ha aiutato a crescere come programmatore. È molto più facile capire ed essere in grado di utilizzare efficacemente qualcosa al livello più alto quando capisci come gestirlo a un livello più basso.

Li trovo utili per modificare rapidamente un file di configurazione su qualche sistema (possibilmente di produzione), a cui ho solo accesso al terminale. Vorrei mai usarlo per sviluppare software in realtà a causa di quanto siano sofisticati gli IDE oggi.

Non ho mai veramente capito perché la gente si preoccupa di parlare dell'ottimizzazione della velocità di digitazione, come se questo fosse il collo di bottiglia dello sviluppo o qualcosa del genere. Non è nemmeno vicino al tempo che salvo dall'usare un IDE.

Inoltre, come si passa dalla tastiera al mouse per rompere il filo del pensiero?

Una volta impostato l'IDE, non dovrai quasi mai preoccuparti di alcuna configurazione. Non è che tu stia costantemente perdendo tempo a capire come fare qualcosa legato all'IDE.