Perché dovrei usare un IDE? [chiuso]

In un'altra domanda, Mark parla molto degli IDE, dicendo "alcune persone non sanno ancora" perché "dovrebbero usarne uno ...". Come qualcuno che usa vim per la programmazione e lavora in un ambiente in cui la maggior parte / tutti i miei colleghi usano vim o emacs per tutto il loro lavoro, quali sono i vantaggi degli IDE? Perché dovrei usarne uno?

Sono sicuro che questo sia un problema grave per alcune persone e non sono interessato a iniziare una guerra di fiamma, quindi per favore rispondi solo con le ragioni per cui ritieni che un approccio basato sull'IDE sia superiore . Non mi interessa sapere perché non dovrei usare un IDE; Non ne uso già uno. Mi interessa sapere "dall'altra parte della recinzione", per così dire.

Se pensi che gli IDE possano essere adatti per alcuni tipi di lavoro ma non per altri, sono anche interessato a capire perché.

Dipende molto dal linguaggio che stai usando, ma in C # e Java trovo gli IDE utili per:

• Navigare rapidamente verso un tipo senza preoccuparsi dello spazio dei nomi, del progetto, ecc
• Navigazione verso i membri trattandoli come collegamenti ipertestuali
• Completamento automatico quando non ricordi a memoria i nomi di tutti i membri
• Generazione automatica di codice
• Refactoring (massiccio)
• Organizza le importazioni (aggiungendo automaticamente le importazioni appropriate in Java, usando le direttive in C #)
• Avviso durante la digitazione (ovvero alcuni errori non richiedono nemmeno un ciclo di compilazione)
• Passa il mouse sopra qualcosa per vedere i documenti
• Mantenere una visualizzazione di file, errori / avvisi / console / unit test ecc. E codice sorgente tutti sullo schermo contemporaneamente in modo utile
• Facilità di esecuzione dei test unitari dalla stessa finestra
• Debug integrato
• Controllo sorgente integrato
• Navigazione verso dove si è verificato un errore di compilazione o un'eccezione di runtime direttamente dai dettagli dell'errore.
• Eccetera!

Tutti questi risparmiano tempo. Sono cose che potrei fare manualmente, ma con più dolore: preferirei programmare.

Completamento del codice. Aiuta molto nell'esplorazione del codice.

La breve risposta sul perché utilizzo un IDE è la pigrizia.

Sono un'anima pigra a cui non piace fare le cose in modo difficile quando invece c'è un modo semplice per farlo. Gli IDE semplificano la vita e fanno appello a noi gente pigra.

Mentre digito il codice, l'IDE verifica automaticamente la validità del codice, posso evidenziare un metodo e premere F1 per ottenere aiuto, fare clic con il tasto destro e selezionare "vai alla definizione" per passare direttamente al punto in cui è definito. Ho premuto un pulsante e l'applicazione, con il debugger collegato automaticamente, viene avviata per me. E così l'elenco continua. Tutte le cose che uno sviluppatore fa quotidianamente sono raccolte sotto lo stesso tetto.

Non è necessario utilizzare un IDE. È molto più difficile non farlo.

Non credo sia giusto fare il classico "editor di testo e finestra della console contro IDE" quando "editor di testo" è veramente emacs. La maggior parte delle funzionalità tipiche di IDE: s sono anche in emacs. O forse hanno anche avuto origine lì, e gli IDE moderni sono principalmente miglioramenti / semplificazioni dell'interfaccia.

Ciò significa che per la domanda originale, la risposta non è così chiara. Dipende da come le persone sul sito in questione usano emacs, se lo usano principalmente come editor di testo o se fanno tutto e usano script personalizzati, apprendono i comandi per le modalità pertinenti, conoscono la codifica del codice e così via.

Vengo a questa domanda dalla direzione opposta. Sono stato educato nella programmazione con pochissimi pitstop nella terra di Makefile + Emacs. Dal mio primo compilatore su DOS, Microsoft Quick C, avevo un IDE per automatizzare le cose. Ho trascorso molti anni a lavorare in Visual C ++ 6.0 e, mentre mi diplomavo in Enterprise Java, ho lavorato con Borland JBuilder e poi mi sono affidato a Eclipse, che è diventato molto produttivo per me.

Durante la mia autodidatta iniziale, il college e ora la mia carriera professionale, ho imparato che qualsiasi importante sviluppo software fatto esclusivamente all'interno dell'IDE diventa controproducente. Lo dico perché la maggior parte degli IDE vuole che tu lavori nel lorostile peculiare di I-control-how-the-world-works. Devi tagliare e tagliare i tuoi progetti lungo le loro linee. Hai gestito le build del tuo progetto usando le loro finestre di dialogo dispari. La maggior parte degli IDE gestisce in modo scadente dipendenze complesse tra progetti e le dipendenze possono essere difficili da far funzionare al 100%. Sono stato in situazioni in cui gli IDE non avrebbero prodotto una build funzionante del mio codice se non avessi fatto un Clean / Rebuild All. Infine, raramente esiste un modo semplice per spostare il software fuori dallo sviluppo e in altri ambienti come QA o Production da un IDE. Di solito è un click click per realizzare tutte le tue unità di distribuzione, o hai uno strumento imbarazzante che il fornitore IDE ti offre per raggruppare le cose. Ma ancora

Ho imparato che, per fare uno sviluppo su larga scala con un team, possiamo essere i più produttivi se sviluppiamo il nostro codice usando un IDE e facciamo tutte le nostre build usando script da riga di comando scritti manualmente. (Ci piace lo sviluppo di Apache Ant per Java.) Abbiamo scoperto che eseguire i nostri script dall'IDE è solo un clic fest o un incubo di automazione per build complesse, è molto più facile (e meno distruttivo) alt + tab su un shell ed eseguire gli script lì.

Le build manuali ci impongono di perdere alcune delle bellezze della moderna IDE come la compilazione in background, ma ciò che otteniamo è molto più critico: build semplici e pulite che possono vivere in più ambienti. La "build con un clic" di cui parlano tutti quei ragazzi agili? Noi ce l'abbiamo. I nostri script di build possono essere richiamati direttamente anche dai sistemi di integrazione continua. La gestione delle build tramite l'integrazione continua ci consente di organizzare e migrare in modo più formale le implementazioni del codice in ambienti diversi e di farci sapere quasi immediatamente quando qualcuno verifica un codice errato che interrompe la build o i test unitari.

In verità, il mio allontanamento del ruolo di IDE dall'IDE non ci ha fatto molto male. Gli strumenti di intellisense e refactoring in Eclipse sono ancora completamente utili e validi: la compilazione in background serve semplicemente a supportare quegli strumenti. E, la peculiare suddivisione dei progetti di Eclipse è stata un modo molto carino per scomporre mentalmente i nostri problemi in un modo che tutti possono capire (comunque un po 'prolisso per i miei gusti). Penso che una delle cose più importanti di Eclipse siano le eccellenti integrazioni SCM, questo è ciò che rende lo sviluppo del team così divertente. Usiamo Subversion + Eclipse, ed è stato molto produttivo e molto facile addestrare il nostro personale a diventare esperti.

Essendo l'autore della risposta che metti in evidenza nella tua domanda, e devo ammettere che arriverai a questo un po 'tardi, dovrei dire che tra le molte ragioni che sono state elencate, la produttività di uno sviluppatore professionista è una delle più abilità molto apprezzate.

Per produttività, intendo la capacità di svolgere il tuo lavoro in modo efficiente con i migliori risultati possibili. Gli IDE lo consentono su molti livelli. Non sono un esperto di Emacs, ma dubito che manchi di tutte le funzionalità dei principali IDE.

La progettazione, la documentazione, il monitoraggio, lo sviluppo, la costruzione, l'analisi, la distribuzione e la manutenzione, pietre miliari chiave in un'applicazione aziendale, possono essere eseguite all'interno di un IDE.

Perché non useresti qualcosa di così potente se avessi la scelta?

Come esperimento, impegnati a usare un IDE per, diciamo, 30 giorni e vedi come ti senti. Mi piacerebbe leggere i tuoi pensieri sull'esperienza.

Avere un IDE ha i seguenti vantaggi:

• La compilazione è di solito "al volo", il che significa che non è più necessario passare alla riga di comando per la compilazione
• Il debug è integrato e averlo in un IDE significa che il debugger a step utilizza effettivamente l'editor sul posto per mostrare visivamente quale codice viene eseguito
• Gli IDE di solito hanno una conoscenza più semantica della lingua in cui stai lavorando e possono mostrarti possibili problemi durante la digitazione. Il refactoring è molto più potente della "ricerca sostituisci".

Ce ne sono molti altri, forse dovresti provarlo.

Gli IDE sono sostanzialmente:

• Editor con completamento del codice, refactoring e documentazione
• Debugger
• Esplora file system
• Client SCMS
• Strumento di costruzione

tutto in un unico pacchetto.

Puoi avere tutto questo (e alcuni altri) usando strumenti separati o semplicemente un ottimo editor programmabile e strumenti extra, come Emacs (anche Vim ma ha un po 'meno IDEbility IMO).

Se ti ritrovi a passare molto da un'utilità all'altra che potrebbe essere integrata nell'ambiente o se ti mancano alcune delle abilità elencate qui (e più completamente in altri post), forse è tempo di passare a un IDE (o per migliorare l'IDEbility del tuo ambiente aggiungendo macro o cosa no). Se ti sei costruito un "IDE" (nel senso che ho menzionato sopra) utilizzando più di un programma, non è necessario passare a un IDE effettivo.

Eclisse:

Avere il controllo del codice, compilare in background, evidenziare i miei errori mentre procedo.

Integrazione con javadoc, suggerendo nomi di variabili con ctrl-Spazio.

Quando compilo, ricevo errori proprio lì. Posso fare doppio clic su un errore e viene visualizzata la riga appropriata.

Davvero ben integrato con JUnit, ctrl-F11 esegue il test, mi dice che i test sono falliti. Se nella finestra di output è presente un'eccezione, posso fare doppio clic su una riga e mi porta alla riga non riuscita. Non solo, ma ctrl-F11 si assicura che tutto sia compilato prima di eseguire i test (il che significa che non dimenticherò mai di farlo).

Integrazione con la formica. Un comando per compilare e distribuire l'applicazione.

Integrazione con i debugger, incluso il debug remoto dei server Web.

Strumenti di refactoring FANTASTICI, alla ricerca di riferimenti a una sezione di codice. Mi aiuta a conoscere l'impatto di un cambiamento.

Tutto sommato, mi rende più produttivo.

Ho usato Emacs come il mio ambiente principale sia per lo sviluppo che per la posta / notizie per circa 10 anni (1994-2004). Ho scoperto il potere degli IDE quando mi sono costretto ad imparare Java nel 2004 e con mia sorpresa mi è piaciuto davvero l'IDE ( IntelliJ IDEA ).

Non entrerò in ragioni specifiche poiché molti di loro sono già stati menzionati qui - ricorda solo che le diverse persone amano caratteristiche diverse. Io e un collega abbiamo usato lo stesso IDE, entrambi abbiamo usato solo una parte delle funzionalità disponibili e non ci è piaciuto vicendevolmente il modo di utilizzare l'IDE (ma entrambi ci è piaciuto l'IDE stesso).

Ma c'è un vantaggio con gli IDE rispetto agli ambienti correlati a Emacs / Vim su cui voglio concentrarmi: dedichi meno tempo all'installazione / configurazione delle funzionalità che desideri.

Con Wing IDE (per Python) sono pronto per iniziare a sviluppare 15-20 minuti dopo l'installazione. Non ho idea di quante ore avrei bisogno per ottenere le funzionalità che utilizzo e funzionanti con Emacs / Vim. :)

Ciò porta sicuramente a un miglioramento della produttività per me. Al punto in cui codice persino le applicazioni Linux in Visual Studio su Vista e quindi utilizzo una macchina virtuale Linux per costruirle.

Non è necessario memorizzare tutti gli argomenti in una chiamata di funzione o metodo, una volta che si inizia a digitarlo, l'IDE ti mostrerà quali argomenti sono necessari. Ottieni procedure guidate per impostare le proprietà del progetto, le opzioni del compilatore, ecc. Puoi cercare elementi in tutto il progetto anziché solo il documento o i file correnti in una cartella. Se ricevi un errore del compilatore, fai doppio clic su di esso e ti porta direttamente alla linea offensiva.

Integrazione di strumenti come editor di modelli, connessione e navigazione in database esterni, gestione di raccolte di "snippet" di codice, strumenti di modellazione della GUI, ecc. tempo e mantiene il processo di sviluppo più efficiente.

Potrebbero esserci ragioni diverse per persone diverse. Per me questi sono i vantaggi.

1. Fornisce un'atmosfera integrata al progetto. Ad esempio, avrò tutti i file dei progetti correlati in un'unica vista.
2. Fornisce una maggiore produttività del codice come
   1. Evidenziazione della sintassi
   2. Riferendosi di assemblee
   3. Intellisense
   4. Vista centralizzata del database e dei relativi file dell'interfaccia utente.
   5. Funzionalità di debug

Alla fine della giornata, mi aiuta a programmare più velocemente di quanto possa fare in un blocco note o in un wordpad. Questa è una buona ragione per preferire un IDE.

Un IDE può essere una scelta "superiore" in base a ciò che uno sviluppatore sta cercando di realizzare.

Un editor di testo può essere "superiore" perché gli IDE sono in genere orientati verso una (o una piccola selezione) di lingue.

Se uno sviluppatore trascorre la maggior parte del suo tempo in una singola lingua o in un "cluster" di linguaggi correlati (come C # e T-SQL), in un sistema operativo, quindi gli strumenti di progettazione della GUI, debug, intellisense, refactoring ecc. Offerti da un buon IDE può essere molto convincente. Se, ad esempio, passi la maggior parte del tuo tempo a lavorare in VB.NET, con forse un po 'di T-SQL di tanto in tanto, in un ambiente Windows, allora saresti abbastanza sciocco non guardare Visual Studio o un IDE comparabile .

Non ho pregiudizi nei confronti di coloro che preferiscono IDE o editor di testo, entrambi possono essere molto produttivi e utili se appresi bene !

Penso che abbia principalmente a che fare con la portata della consapevolezza per lo sviluppatore. L'IDE fornisce una visione macroscopica del contesto di lavoro dello sviluppatore. È possibile visualizzare contemporaneamente gerarchie di classi, risorse di riferimento, schemi di database, riferimenti della guida dell'SDK, ecc. E con così tante cose influenzate e influenzate dalle sequenze di tasti e dal volume crescente di architetture e intersezioni architettoniche, diventa sempre più difficile funziona solo da un'isola di codice alla volta.

OTOH, "solo io e Vim e le pagine man" mi dà una visione microscopica molto più snella, ma intensa e precisa, del mio lavoro. Va bene se ho una base di codice ben progettata, ben partizionata, scarsamente accoppiata, altamente coesa, costruita in una lingua con un set di librerie statiche su cui lavorare - non la tua situazione tipica, specialmente quando le dimensioni del team di sviluppo crescono e rimodellano la struttura del codice nel tempo, distanza e preferenze personali.

Attualmente sto lavorando a progetti in Flex e .NET. Una delle cose più belle di Flex è il numero di modi diversi per realizzare una cosa standard: estrarre dati da un database, aprire / chiudere / leggere / scrivere un file, ecc. (Eppure sto usando Flex Builder / Eclipse IDE - un tipico esempio pesante come VS, perché sto ancora imparando le basi e ho bisogno delle ruote di allenamento. Mi aspetto di tornare a Vim una volta che sono sicuro dei miei schemi.) In questa vista, posso fare quello Devo fare professionalmente conoscendo alcune cose davvero molto bene.

OTOH, non riesco a immaginare di arrivare a quel punto con .NET perché la vista che mi aspetto di mantenere continua ad espandersi e spostarsi. C'è molta meno integrità concettuale e, nel corso di diversi mesi, diversi sviluppatori su un progetto, molta meno coerenza, ma l'IDE lo supporta, forse lo incoraggia. Quindi lo sviluppatore deve davvero (e può più facilmente) conoscere molte più cose in modo adeguato. Il che ha anche il vantaggio di aiutarli a rispondere (o persino a capire) una percentuale molto più alta delle domande su StackOverflow. Cioè possiamo avere una pila di conoscenza più profonda. E siamo in grado di rispondere a una più ampia varietà di annunci desiderati.

Le cose possono andare troppo lontano in entrambe le direzioni. Forse con l'ambito "solo editor", è come "se hai solo un martello, tutto sembra un chiodo". Con l'approccio IDE, per qualsiasi cosa tu voglia fissare insieme, hai una vasta selezione di elementi di fissaggio e relative gamme di strumenti tra cui scegliere: nali / martelli, viti / cacciaviti, bulloni / chiavi, adesivi / pistole per colla / morsetti, magneti e ancora e ancora - tutto a portata di mano (con una procedura guidata per aiutarti a iniziare).

Non pensarlo come esclusivo. Usa l'IDE per i vantaggi che offre e passa a vim / editor di testo preferito quando hai bisogno di un focus serio.

Trovo l'IDE migliore per il refactoring, la navigazione e il debug e per capire cosa fare. Le piccole cose vengono quindi fatte proprio nell'IDE, le grandi cose che capovolgo per vim per finire il lavoro.

Oltre alle altre risposte, adoro combinare la potenza di sviluppo di un IDE con la potenza di editing di Vim usando qualcosa come ViPlugin per Eclipse .

IntelliSense , il debugger integrato e la finestra immediata mi rendono enormemente più produttivo ( Visual Studio 2008 ). Con tutto a portata di mano, posso tenere la stragrande maggioranza di un enorme progetto dentro la mia testa mentre scrivo codice. Microsoft potrebbe continuare a far cadere la palla sui propri sistemi operativi, ma Visual Studio è uno dei migliori prodotti mai sviluppati.

Non capisco cosa stai chiedendo. Mi chiedi "Dovrei usare un IDE invece di ...", ma non capisco quale sia l'alternativa - Vim ed Emacs svolgono molte funzioni che qualsiasi IDE ti darà. L'unico aspetto che non gestiscono il fatto che un IDE più grande possa essere qualcosa come i progettisti dell'interfaccia utente. Quindi la tua domanda si riduce semplicemente a "quale IDE dovrei usare" con argomenti da formulare per il regno più semplice di Vim ed Emacs.

Per me, un IDE è migliore perché consente una navigazione più rapida nel codice che è importante se hai qualcosa in mente da implementare. Supponiamo che tu non usi un IDE, ci vuole più tempo per arrivare a destinazione. I tuoi pensieri possono essere interrotti più spesso. Significa che è necessario premere più clic / più tasti. Bisogna concentrarsi maggiormente sul pensiero su come implementare le cose. Naturalmente, puoi anche scrivere le cose, ma poi si deve saltare tra la progettazione e l'implementazione. Inoltre, un designer della GUI fa la differenza. Se lo fai a mano, potrebbe richiedere più tempo.

Gli IDE basati su GUI come Visual Studio ed Eclipse presentano numerosi vantaggi rispetto agli IDE basati su testo come Emacs o vim a causa delle loro capacità di visualizzazione:

• Anteprima WYSIWYG e editing live per la progettazione della GUI
• Editor di proprietà efficienti (ad es. Selezione del colore mediante una tavolozza GUI, inclusi arresti gradiente di posizionamento, ecc.)
• Rappresentazione grafica di contorni di codice, interrelazioni di file, ecc
• Uso più efficiente del settore immobiliare dello schermo per mostrare punti di interruzione, segnalibri, errori, ecc
• Migliore supporto del trascinamento della selezione con il sistema operativo e altre applicazioni
• Modifica integrata di disegni, immagini, modelli 3D, ecc
• Visualizzazione e modifica di modelli di database

Fondamentalmente con un IDE basato su GUI puoi ottenere più informazioni utili sullo schermo in una sola volta e puoi visualizzare / modificare parti grafiche della tua applicazione con la stessa facilità delle porzioni di testo.

Una delle cose più interessanti da sperimentare come sviluppatore è la modifica di un metodo che calcola alcuni dati e vede l'output dal vivo del tuo codice visualizzato graficamente in un'altra finestra, proprio come l'utente lo vedrà quando avvierai l'app. Questa è la modifica di WYSIWYG!

Gli IDE basati su testo come Emacs e vim possono aggiungere funzionalità come il completamento del codice e il refactoring nel tempo, quindi a lungo termine il loro limite principale è il modello di visualizzazione basato su testo.

Uso quasi esclusivamente Vim (quasi perché sto cercando di imparare emacs ora) per tutte le mie cose di sviluppo. Penso che la semplice intuitività (ovviamente dalla GUI) sia il motivo principale per cui alla gente piace usare gli IDE. Essendo intuitivo, è richiesto poco o nessun sovraccarico di apprendimento dello strumento. Minore è il sovraccarico di apprendimento, più possono svolgere il lavoro.

Un IDE consente di lavorare più velocemente e più facilmente ... Ho notato che ho trascorso molto tempo a navigare nel codice in un semplice editor di testo ...

In un buon IDE, quel tempo diminuisce se l'IDE supporta il salto alle funzioni, alla posizione di modifica precedente, alle variabili ... Inoltre, un buon IDE riduce il tempo di sperimentazione con funzionalità e progetti linguistici diversi, come il tempo di avvio può essere piccolo.

Un paio di ragioni che mi vengono in mente per l'utilizzo di un IDE:

• L'aiuto integrato è uno dei preferiti.
• Refactor integrato con anteprima di Visual Studio
• IntelliSense , evidenziazione della sintassi, facilità di navigazione per grandi progetti, debug integrato, ecc. (Anche se so che con i componenti aggiuntivi è possibile ottenerne molti con Emacs e Vim ).
• Inoltre, penso che gli IDE in questi giorni abbiano una base di utenti più ampia e probabilmente più persone che sviluppano componenti aggiuntivi per loro, ma potrei sbagliarmi.

E francamente, mi piace il mio topo. Quando uso solo editor basati su testo, mi sento solo.

Risparmia tempo per lo sviluppo
Semplifica la vita fornendo funzionalità come il debug integrato, intellisense.

Ce ne sono molti, ma ti consigliamo di usarne uno, sono più che ovvi.

Non sono sicuro che ci sia una chiara linea di demarcazione tra un editor di testo e un IDE. Ti piace Notepad a un'estremità della scala e i migliori IDE moderni all'altra, ma ci sono molte cose in mezzo. La maggior parte degli editor di testo ha l'evidenziazione della sintassi; i redattori rivolti ai programmatori hanno spesso varie altre funzioni come la facile navigazione del codice e il completamento automatico. Emacs ti consente persino di integrare un debugger. Gli IDE di dieci anni fa avevano molte meno funzioni per aiutare i programmatori di quanto ti aspetteresti da un serio editor di testi in questi giorni.

Il motivo principale per usarne uno è quando il codice supera i 100 file.

Anche se i tag possono fare il lavoro, alcuni IDE hanno un buon modo per navigare i file facilmente in modo super veloce.

Risparmia tempo quando hai molto lavoro da fare.

Per me è solo la versione GUI di tutto ciò che abbiamo fatto nei bei vecchi tempi del terminale. Concordo sempre sul fatto che gli IDE non sono molto superiori perché nascondono molte cose, specialmente per quanto riguarda i collegamenti, ma in alcuni casi presentano un notevole vantaggio, ad esempio con alcune piattaforme di sviluppo come Qt.

Alcuni IDE come visual di altri sembrano addirittura analizzare il codice durante la digitazione e rilevare errori prima ancora che vengano compilati: sembra logico che solo un IDE possa lavorare a stretto contatto con un compilatore per rilevare immediatamente il problema nell'origine digitata.

La mia risposta selvaggia che esiste la guerra di fiamma IDE / riga di comando è solo perché l'edificio eseguibile C / C ++ non è gestito molto bene da un punto di vista standardizzato, a differenza del linguaggio D; ogni piattaforma gestisce la compilazione / collegamento / etc a modo suo, quindi per renderlo meno disordinato creano un IDE.

Dal tuo punto di vista potrebbe essere più semplice utilizzare la riga di comando, se ci fosse stato un solo compilatore con opzioni standard, sarebbe stato facile, ma la verità è che C / C ++ è flessibile, quindi alla fine tutta la piattaforma fai a modo suo, quindi l'IDE non spreca spiegando come farlo.

Se puoi imparare come un eseguibile parla al kernel o se sai qualcosa sulla progettazione del compilatore, forse c'è un modo di lavorare con una riga di comando corretta, ma dubito che tu abbia.

Microsoft o Apple, per quanto malvagi sarebbero, devono proporre un modo semplice per creare un'applicazione senza entrare nei dettagli, e poiché la creazione di un'applicazione dipende direttamente dall'architettura del sistema operativo, difficilmente sarà "standard" come la riga di comando è.

Per dirla in applicazioni semplici, grandi e complesse in cui non si vuole scavare troppo in profondità in ciò che fa -> IDE, piccoli pezzi di software o semplice progettazione di software di sistema -> riga di comando. Tranne ovviamente quelle belle librerie che incorporano un Makefile, ma questa è un'altra storia.

Inoltre, penso che gli IDE vengano utilizzati quando l'applicazione fornita ha qualcosa a che fare con, ironicamente, una GUI o qualcosa che ha un'interfaccia o è direttamente legata a un sistema operativo, quindi, ancora una volta, è anche per le persone che useranno un'interfaccia utente / GUI senza sapere come funziona, mentre le persone che programmeranno i sistemi non avranno bisogno di tutto.

L'IDE è solo una merda moderna, ma penso che tra 100 anni la riga di comando esisterà ancora.

Mi piace un IDE perché mette molte funzionalità a portata di mano. La modifica / compilazione / visibilità dei file nel progetto sono tutte cose che apprezzo in un IDE. Ora uso Visual Studio ma in una vita precedente ho usato SlickEdit e ho scoperto che ha reso il mio processo di sviluppo più snello rispetto a quando non lo stavo usando.

C'è solo una cosa da considerare quando si decide se utilizzare un IDE o meno, ed è se ti rende più produttivo o meno.

Breve domanda così breve risposta :)

Dipende molto da cosa stai facendo e dalla lingua in cui lo stai facendo. Personalmente, tendo a non usare un IDE (o "il mio IDE è composto da 3 xterm che eseguono vim, uno che esegue un client di database e uno con un bash prompt o tailing log ", a seconda di come si definisce" IDE ") per la maggior parte del mio lavoro, ma, se dovessi trovarmi a sviluppare una GUI nativa della piattaforma, raggiungerei un IDE appropriato per la lingua in un istante: IMO, IDE e modifica grafica dei moduli sono chiaramente realizzati l'uno per l'altro.