Domanda Persona inesperta ma con interesse e voglia

Stato
Discussione chiusa ad ulteriori risposte.

TestaDiPixel

Utente Bronze
21 Marzo 2016
3
1
0
29
Salve a tutti.
Sono una persona che non sa nulla, nemmeno la basi ma che ha voglia di capirne qualcosa. Sono affascinato da questo genere di cose e mi chiedevo se qualcuno potesse dedicare anche poco tempo e una riga per consigliarmi da dove e come partire. Vorrei in particolare imparare a programmare qualcosina (programmi) partendo da DEV-C/DEV-C ++ per poi usare Java e così via.
Grazie per l'attenzione.
 
Salve a tutti.
Sono una persona che non sa nulla, nemmeno la basi ma che ha voglia di capirne qualcosa. Sono affascinato da questo genere di cose e mi chiedevo se qualcuno potesse dedicare anche poco tempo e una riga per consigliarmi da dove e come partire.
Grazie per l'attenzione.
che cosa vorresti imparare a fare?
 
Salve a tutti.
Sono una persona che non sa nulla, nemmeno la basi ma che ha voglia di capirne qualcosa. Sono affascinato da questo genere di cose e mi chiedevo se qualcuno potesse dedicare anche poco tempo e una riga per consigliarmi da dove e come partire. Vorrei in particolare imparare a programmare qualcosina (programmi) partendo da DEV-C/DEV-C ++ per poi usare Java e così via.
Grazie per l'attenzione.
Prima di programmare c'è un'altra cosa che vorrei suggerirti però prima ti chiedo, utilizzi un sistema operativo Windows?
 
Non utilizzare DEV-C++. Primo perché lo sviluppo è spesso discontinuo: può capitare che non vengano rilasciati aggiornamenti per lunghi periodi. Secondo perché è un IDE: se vuoi imparare a programmare, gli IDE sono un danno.
Usa solo un editor di testo semplice, e compila da riga di comando. Gli IDE fanno parte (troppo) del lavoro al posto tuo e questo non è sicuramente un bene per chi impara (e, imho, anche per chi programma professionalmente).
Se stai da Windows, c'è Notepad++. Per il C e il C++ c'è MinGW per compilare. Da Linux può andar bene gedit come editor, e ovviamente GCC per compilare.
Il consiglio però è di passare a Linux. A meno che usi il computer per giocare, Windows non è necessario - ed è una palla al piede per molti aspetti. Se non sei pratico di Linux, prova Linux Mint - chi inizia ci si trova sempre bene.
Per il resto, hai bisogno di un manuale di programmazione.
 
Non utilizzare DEV-C++. Primo perché lo sviluppo è spesso discontinuo: può capitare che non vengano rilasciati aggiornamenti per lunghi periodi. Secondo perché è un IDE: se vuoi imparare a programmare, gli IDE sono un danno.
Usa solo un editor di testo semplice, e compila da riga di comando. Gli IDE fanno parte (troppo) del lavoro al posto tuo e questo non è sicuramente un bene per chi impara (e, imho, anche per chi programma professionalmente).
Se stai da Windows, c'è Notepad++. Per il C e il C++ c'è MinGW per compilare. Da Linux può andar bene gedit come editor, e ovviamente GCC per compilare.
Il consiglio però è di passare a Linux. A meno che usi il computer per giocare, Windows non è necessario - ed è una palla al piede per molti aspetti. Se non sei pratico di Linux, prova Linux Mint - chi inizia ci si trova sempre bene.
Per il resto, hai bisogno di un manuale di programmazione.

Ciao Speed.
Io ho sempre usato Dev-C++ e ora sto usando CodeBlocks.
Cosa mi consigli? Ho Notepad++ anche.
Perché gli IDE sono un danno?
 
Secondo me visto che non hai mai fatto nulla devo c++ va più che bene per incominciare

Inviato dal mio ONE A2003 utilizzando Tapatalk
 
Perché gli IDE sono un danno?
I compilatori (Codeblock/Dev) aiutano molto
Secondo me visto che non hai mai fatto nulla devo c++ va più che bene per incominciare
Può essere giusto utilizzare un IDE per accelerare i tempi di sviluppo quando si lavora ad un progetto (e quindi, si sa già programmare bene, molto bene). Ma quando si deve imparare assolutamente no.
Un'eccessiva dipendenza da IDE (sopratutto se si parla di un programmatore novizio, ma vale anche per i professionisti) può causare vari problemi. Gli IDE sono fatti per semplificare il lavoro. Per semplificarlo, quello che fanno è fare parte del lavoro al posto del programmatore. Ad esempio: quando un programmatore deve compilare un programma da IDE, clicca semplicemente su "Compila". Se non usasse un IDE dovrebbe: aprire il terminale; richiamare il compilatore con i giusti parametri affinché compili il sorgente in codice oggetto; richiamare il linker con i giusti parametri affinché traduca il codice oggetto in eseguibile.
In generale un IDE fa apparire qualcosa di complesso come più semplice, nascondendone alcuni aspetti più complessi.
Quindi il programmatore novizio che deve ancora imparare, non capisce come funzionano molte cose: riprendendo l'esempio di prima, ci sono oggi molti neo-programmatori IDE-dipendenti (sopratutto provenienti dal .NET) che non hanno idea di che cosa sia un linker, o pensano addirittura che compilatore e IDE siano la stessa cosa e che non si possa programmare senza IDE. Se ne volete conoscere qualcuno, basta che fate un giro nella sezione VB.NET di inforge.
Gli IDE tendono a ridurre la complessità anche dello stesso codice. Ad esempio, un IDE che faccia anche da strumento RAD per le interfacce grafiche genera automaticamente del codice, che generalmente nasconde al programmatore. Se uno non sa (o semplicemente non gli viene in mente perché l'IDE glielo nasconde - e questo può capitare anche ad un programmatore professionista) che c'è del codice generato automaticamente dall'IDE, quando qualcosa non funziona nel programma (e magari la causa è proprio quel codice autogenerato) non ci pensa ad andare a vedere quel codice nascosto - e finisce quindi per sbattere la testa contro il muro tante volte, o addirittura a escogitare workaround assurdi.
Usare sempre un IDE inoltre fa perdere le proprie abilità e competenze anche al programmatore esperto, riportandolo ad essere nuovamente inesperto. Ad esempio, se un programmatore impara a compilare da linea di comando ma poi per i tre anni successivi usa sempre ed esclusivamente un IDE, finirà che non ricorda più come compilare da linea di comando. Quando un giorno avrà necessariamente bisogno di compilare da linea di comando per specificare esplicitamente degli switch che l'IDE non specifica al posto suo, si troverà di nuovo in difficoltà. Inoltre il programmatore che non ha mai usato altro che IDE non saprà nemmeno della possibilità di modificare il comportamento del compilatore tramite degli switch da linea di comando. O non saprà che è possibile creare interfacce grafiche molto più personalizzate se abbandona l'ambiente RAD e si mette a sviluppare solo da codice.

Può andar bene usare degli IDE per produttività (imho, no), ma chi li usa deve sapere perfettamente tutto quello che l'IDE fa al posto suo e come. Altrimenti, quando ci saranno dei problemi o quando dovrà fare qualcosa di più, sono caxxi.
Imho gli IDE non andrebbero MAI usati in quanto:
  • Non si rischia assolutamente di dimenticare ciò che si ha imparato, in quanto si continua a usare sempre tutto (a compilare sempre da linea di comando) - anche gli aspetti più basilari del linguaggio spesso si dimenticano usando gli IDE, in quanto vengono gestiti automaticamente da molti IDE (gli IDE inseriscono spesso automaticamente pezzi di codice che devono per forza starci: parentesi graffe, punti e virgola, ecc.);
  • Si evita che problemi dell'IDE facciano perdere tempo;
  • Si evita di dimenticarsi che si può fare di più rispetto a ciò che l'IDE permette, e ogni volta che si inizia un nuovo progetto si hanno in mente subito tutte le possibilità, e non solo quelle che offre l'IDE;
  • Se si usa un IDE, bisogna (per i motivi sopra) tenersi allenati lavorando a volte senza IDE (per non diventare troppo IDE-dipendenti). Tanto vale fare sempre a meno dell'IDE in modo da tenersi SEMPRE allenati;
  • Se si lavora a progetti open-source o in team con altri, utilizzando strumenti di version control come git o anche semplicemente passandosi i sorgenti manualmente, i codici autogenerati e l'altra sporcizia generata dai propri IDE può causare fastidiosi problemi ad altre persone che invece non fanno uso di IDE o, peggio, usano altri IDE;
  • Gli IDE spesso danno dei "consigli" sul codice. Ad esempio, se c'è un errore, possono dirti "dovresti fare così...". Un programmatore finisce per accettare la soluzione data dall'IDE senza valutare se è la soluzione ottimale. L'IDE finisce per programmare al posto del programmatore: per programmare ci vuole un cervello, un'intelligenza (o il programmatore sarebbe inutile) - è sempre una pessima idea delegare il lavoro all'IDE;
  • Non puoi automatizzare alcune procedure di sviluppo in modo personalizzato. L'IDE automatizza certe procedure certo (come la compilazione), ma lo fa a modo suo. La potenza del terminale (qui intendo il terminale vero, ossia quello di Linux, non il prompt di Windows) è proprio quella di poter automatizzare le operazioni e di combinare insieme più programmi/comandi per eseguire task anche molto complessi. Esempi sono ovviamente Bash e i Makefile (compilazione), grep e sed (grep e sed sono molto più "potenti" di un qualsiasi strumento di "find & replace" di qualsiasi IDE);
  • L'IDE spesso nasconde anche le dipendenze del codice. Quanto spesso capita che alcuni programmatori (spesso .NET) rilasciano programmi che non funzionano perché mancano delle dipendenze? Questo perché ne hanno fatto uso senza sapere della loro esistenza, perché l'IDE gliele ha "nascoste";
  • Si finisce per innamorarsi di un IDE e non essere in grado di passare ad altro, neanche sul momento del bisogno;
  • È pigrizia pura.
Gli esempi che ho riportato (compilazione, strumenti RAD, grep e sed, shell script, dipendenze, codici autogenerati, ecc.) sono solo alcuni esempi: lo stesso discorso si può applicare a qualsiasi altra semplificazione che gli IDE fanno al lavoro del programmatore.

Cosa mi consigli? Ho Notepad++ anche.
Per Windows Notepad++ va benissimo. Ma il consiglio è che passi a Linux. Ho già parlato sopra dei vantaggi del terminale Linux e di un linguaggio di scripting completo come Bash, non che di utility come grep e sed e tante altre, e della possibilità di combinare insieme più programmi. Non vorrei ora soffermarmi su altri motivi, che riguardano il design di Linux rispetto a Windows: che è migliore sicuramente dal punto di vista dello sviluppatore, e imho anche da qualsiasi altro punto di vista. Già "everything is a file", "open-source" e "shell script" dovrebbero essere sufficienti a convincere un qualsiasi programmatore (e non solo) a passare a Linux.
Su Linux, per iniziare, gedit va benissimo. Per chi è più esperto ci sono strumenti più avanzati e personalizzabili come vim e microemacs e tanti altri tra cui scegliere.
 
  • Mi piace
Reazioni: Keep Working
Può essere giusto utilizzare un IDE per accelerare i tempi di sviluppo quando si lavora ad un progetto (e quindi, si sa già programmare bene, molto bene). Ma quando si deve imparare assolutamente no.
Un'eccessiva dipendenza da IDE (sopratutto se si parla di un programmatore novizio, ma vale anche per i professionisti) può causare vari problemi. Gli IDE sono fatti per semplificare il lavoro. Per semplificarlo, quello che fanno è fare parte del lavoro al posto del programmatore. Ad esempio: quando un programmatore deve compilare un programma da IDE, clicca semplicemente su "Compila". Se non usasse un IDE dovrebbe: aprire il terminale; richiamare il compilatore con i giusti parametri affinché compili il sorgente in codice oggetto; richiamare il linker con i giusti parametri affinché traduca il codice oggetto in eseguibile.
In generale un IDE fa apparire qualcosa di complesso come più semplice, nascondendone alcuni aspetti più complessi.
Quindi il programmatore novizio che deve ancora imparare, non capisce come funzionano molte cose: riprendendo l'esempio di prima, ci sono oggi molti neo-programmatori IDE-dipendenti (sopratutto provenienti dal .NET) che non hanno idea di che cosa sia un linker, o pensano addirittura che compilatore e IDE siano la stessa cosa e che non si possa programmare senza IDE. Se ne volete conoscere qualcuno, basta che fate un giro nella sezione VB.NET di inforge.
Gli IDE tendono a ridurre la complessità anche dello stesso codice. Ad esempio, un IDE che faccia anche da strumento RAD per le interfacce grafiche genera automaticamente del codice, che generalmente nasconde al programmatore. Se uno non sa (o semplicemente non gli viene in mente perché l'IDE glielo nasconde - e questo può capitare anche ad un programmatore professionista) che c'è del codice generato automaticamente dall'IDE, quando qualcosa non funziona nel programma (e magari la causa è proprio quel codice autogenerato) non ci pensa ad andare a vedere quel codice nascosto - e finisce quindi per sbattere la testa contro il muro tante volte, o addirittura a escogitare workaround assurdi.
Usare sempre un IDE inoltre fa perdere le proprie abilità e competenze anche al programmatore esperto, riportandolo ad essere nuovamente inesperto. Ad esempio, se un programmatore impara a compilare da linea di comando ma poi per i tre anni successivi usa sempre ed esclusivamente un IDE, finirà che non ricorda più come compilare da linea di comando. Quando un giorno avrà necessariamente bisogno di compilare da linea di comando per specificare esplicitamente degli switch che l'IDE non specifica al posto suo, si troverà di nuovo in difficoltà. Inoltre il programmatore che non ha mai usato altro che IDE non saprà nemmeno della possibilità di modificare il comportamento del compilatore tramite degli switch da linea di comando. O non saprà che è possibile creare interfacce grafiche molto più personalizzate se abbandona l'ambiente RAD e si mette a sviluppare solo da codice.

Può andar bene usare degli IDE per produttività (imho, no), ma chi li usa deve sapere perfettamente tutto quello che l'IDE fa al posto suo e come. Altrimenti, quando ci saranno dei problemi o quando dovrà fare qualcosa di più, sono caxxi.
Imho gli IDE non andrebbero MAI usati in quanto:
  • Non si rischia assolutamente di dimenticare ciò che si ha imparato, in quanto si continua a usare sempre tutto (a compilare sempre da linea di comando) - anche gli aspetti più basilari del linguaggio spesso si dimenticano usando gli IDE, in quanto vengono gestiti automaticamente da molti IDE (gli IDE inseriscono spesso automaticamente pezzi di codice che devono per forza starci: parentesi graffe, punti e virgola, ecc.);
  • Si evita che problemi dell'IDE facciano perdere tempo;
  • Si evita di dimenticarsi che si può fare di più rispetto a ciò che l'IDE permette, e ogni volta che si inizia un nuovo progetto si hanno in mente subito tutte le possibilità, e non solo quelle che offre l'IDE;
  • Se si usa un IDE, bisogna (per i motivi sopra) tenersi allenati lavorando a volte senza IDE (per non diventare troppo IDE-dipendenti). Tanto vale fare sempre a meno dell'IDE in modo da tenersi SEMPRE allenati;
  • Se si lavora a progetti open-source o in team con altri, utilizzando strumenti di version control come git o anche semplicemente passandosi i sorgenti manualmente, i codici autogenerati e l'altra sporcizia generata dai propri IDE può causare fastidiosi problemi ad altre persone che invece non fanno uso di IDE o, peggio, usano altri IDE;
  • Gli IDE spesso danno dei "consigli" sul codice. Ad esempio, se c'è un errore, possono dirti "dovresti fare così...". Un programmatore finisce per accettare la soluzione data dall'IDE senza valutare se è la soluzione ottimale. L'IDE finisce per programmare al posto del programmatore: per programmare ci vuole un cervello, un'intelligenza (o il programmatore sarebbe inutile) - è sempre una pessima idea delegare il lavoro all'IDE;
  • Non puoi automatizzare alcune procedure di sviluppo in modo personalizzato. L'IDE automatizza certe procedure certo (come la compilazione), ma lo fa a modo suo. La potenza del terminale (qui intendo il terminale vero, ossia quello di Linux, non il prompt di Windows) è proprio quella di poter automatizzare le operazioni e di combinare insieme più programmi/comandi per eseguire task anche molto complessi. Esempi sono ovviamente Bash e i Makefile (compilazione), grep e sed (grep e sed sono molto più "potenti" di un qualsiasi strumento di "find & replace" di qualsiasi IDE);
  • L'IDE spesso nasconde anche le dipendenze del codice. Quanto spesso capita che alcuni programmatori (spesso .NET) rilasciano programmi che non funzionano perché mancano delle dipendenze? Questo perché ne hanno fatto uso senza sapere della loro esistenza, perché l'IDE gliele ha "nascoste";
  • Si finisce per innamorarsi di un IDE e non essere in grado di passare ad altro, neanche sul momento del bisogno;
  • È pigrizia pura.
Gli esempi che ho riportato (compilazione, strumenti RAD, grep e sed, shell script, dipendenze, codici autogenerati, ecc.) sono solo alcuni esempi: lo stesso discorso si può applicare a qualsiasi altra semplificazione che gli IDE fanno al lavoro del programmatore.


Per Windows Notepad++ va benissimo. Ma il consiglio è che passi a Linux. Ho già parlato sopra dei vantaggi del terminale Linux e di un linguaggio di scripting completo come Bash, non che di utility come grep e sed e tante altre, e della possibilità di combinare insieme più programmi. Non vorrei ora soffermarmi su altri motivi, che riguardano il design di Linux rispetto a Windows: che è migliore sicuramente dal punto di vista dello sviluppatore, e imho anche da qualsiasi altro punto di vista. Già "everything is a file", "open-source" e "shell script" dovrebbero essere sufficienti a convincere un qualsiasi programmatore (e non solo) a passare a Linux.
Su Linux, per iniziare, gedit va benissimo. Per chi è più esperto ci sono strumenti più avanzati e personalizzabili come vim e microemacs e tanti altri tra cui scegliere.
Ho appena finito di leggere.
Leggendo mi hai convinto a passare dai software IDE a Notepad++.
Purtroppo, anche se ho Kali Linux installato su macchina virtuale, non posso sfruttarlo per problemi alla tastiera.
Una buona guida (anche su Inforge se c'è) per compilare senza IDE dove posso trovala?
Ah e soprattutto ti ringrazio per aver spiegato bene questa cosa.
Non ne sapevo praticamente niente... Grazie!
 
Ci tengo a sottolineare che quanto detto da @SpeedJack è molto discutibile.
Gli IDE sono degli strumenti costruiti dai programmatori per i programmatori, il fatto che li usano anche i pivelli è un altro discorso. Alla fine il compito principale di un programmatore è scrivere software per automatizzare alcuni processi: perché imparare a memoria gli argomenti da passare a un compilatore quando posso scrivere un software che mi automatizza questo processo? Perché devo scrivere il noioso codice pieno di coordinate per disegnare l'interfaccia grafica quando posso automatizzare anche questo?

Finché scriviamo il programmino di due righe possiamo fare anche tutto a mano, ma nel momento in cui abbiamo davanti un sorgente spezzettato in tanti file, ognuno in una cartella diversa e in gran parte scritto da altre persone, un IDE diventa quasi indispensabile. Perché devo fare avanti e indietro tra i files per vedere quali sono i metodi di una classe e i parametri di una funzione, quando qualcuno ha scritto un programma che ti apre un popup con tutte le informazioni che ti possono servire e magari ti reindirizza pure alla documentazione?

Quote: "Non si rischia assolutamente di dimenticare ciò che si ha imparato"

Chi impara molto bene è anche in grado di colmare quel dubbio (eg. che argomenti devo passare al compilatore) in poco tempo. È davvero così indispensabile ricordarsi ogni cavillo sintattico (eg. la definizione del main con i parametri nel C) quando il compito vero dovrebbe essere incentrato sulla semantica?

Quote: "Si evita che problemi dell'IDE facciano perdere tempo"
Ma gli IDE sono pensati per fare esattamente l'opposto, te lo fanno risparmiare il tempo. Per ogni secondo che perdi per un problema proprio dell'IDE, c'è un ora che risparmi. Se non è così allora devi semplicemente cambiare l'IDE perché quello che stai usando è troppo buggato.

Quote: "Se si lavora a progetti open-source o in team con altri, utilizzando strumenti di version control..."
Gli strumenti di versioning sono già pensati per risolvere questo tipo di problemi, pensa al .gitignore. Vanno in direzione di standardizzare la directory tree e ormai la maggior parte degli IDE automatizza anche l'uso di questi tools.

Quote: "Gli IDE spesso danno dei "consigli" sul codice"

I consigli sul codice (che il più delle volte raccolgono dal compilatore, quindi li vedi solo in anticipo rispetto a un text editor) sono probabilmente una delle features più utile. Se c'è qualcosa di strano cercano è meglio saperlo subito, ti permette di evitare di scrivere ulteriore codice che si appoggia a un errore che troveresti solo in fase di compilazione.
Certo... se il programmatore è "lo stupido" allora tutto diventa un aspetto negativo, ma se il programmatore è "il programmatore" allora è una feature molto utile. D'altronde gli IDE sono scritti da programmatori per programmatori, qualcuno pensa che i consigli siano dannosi? Qualcuno ha messo la spunta per disattivarli.

Quote: "grep e sed sono molto più "potenti" di un qualsiasi strumento di "find & replace" di qualsiasi IDE"
E qui ci sta un bel <citation needed>
Con il find&replace di un IDE puoi fare cose del tipo cambiare il nome di una variabile senza toccare lo stesso nome fuori dallo scope che stai considerando. Puoi ugualmente fare il search con le regex. Chi ci dice che sotto il find e replace non ci sia proprio grep e sed? Chi ci dice che l'IDE non ti permetta di avere un mini terminale dal quale lanciare direttamente i comandi? E, se non fosse così, perché non possiamo aprire un terminale, fare i "lavori complessi" con grep, sed e tutto il resto, per poi tornare all'IDE (che ci chiederà di aggiornare gli eventuali file modificati)?
Alla fine è uno strumento di automazione e va visto come tale, puoi metterlo momentaneamente da parte se preferisci usare altro.

Quote: "alcuni programmatori (spesso .NET) rilasciano programmi che non funzionano"

La negligenza dei programmatori non è da attribuire agli IDE. Se qualcuno è così in gamba da postare cose che non funzionano (per qualsiasi ragione), probabilmente non dovresti interessarti ad usare quella roba.

Quote: "Si finisce per innamorarsi di un IDE e non essere in grado di passare ad altro"

E questo vale anche nel momento in cui io vengo a metterti sotto le mani un ambiente Windows e addio a bash, coreutils, gcc, gdb e compagnia cantante. Molte di queste cose sono cross platform mi dirai, beh... lo sono anche molti IDE. Tu stesso stai consigliando di passare a Linux, in teoria il sistema operativo (così come l'IDE o text editor che sia) non fa il programmatore.


Alcune considerazioni le ho fatte anche solo per dare un secondo punto di vista, giusto per far vedere anche l'altro lato della medaglia. A dire il vero io stesso utilizzo un text editor (per una serie di motivi che credo di aver spiegato in un altro thread), però sono consapevole di quali sono i benefici degli IDE ed è per questa ragione nella guida che ho linkato nel post precedente (e che consiglio a tutti di leggere) ho consigliato di partire direttamente da un IDE (uno buono però!). Se si deve imparare qualcosa, tanto vale imparare ciò che si usa nel mondo professionale.
Il fatto che alcuni processi siano automatizzati non va assolutamente visto come uno svantaggio, saranno anche automatizzati, ma non vuol dire che non vadano imparati. È altrettanto dannoso imparare a memoria memoria i comandi da passare al terminale per fare una qualsiasi cosa. Chi non sa cosa sta facendo, IDE o non IDE, al primo problema che incontra si ritrova bloccato.


Una buona guida (anche su Inforge se c'è) per compilare senza IDE dove posso trovala?
Se la tua domanda è semplicemente "qual'è il comando?" allora puoi trovare la risposta nella guida che ho linkato nel post sopra (è anche in rilievo in questa sezione). Se vuoi sapere come usare (in dettaglio) il compilatore allora devi cercare la guida per il tuo compilatore (eg. man gcc) e se invece vuoi sapere a grandi linee cosa fa un compilatore e cose di questo tipo, allora puoi aprire un thread apposta.
 
Con il find&replace di un IDE puoi fare cose del tipo cambiare il nome di una variabile senza toccare lo stesso nome fuori dallo scope che stai considerando. Puoi ugualmente fare il search con le regex.

Una buona guida (anche su Inforge se c'è) per compilare senza IDE dove posso trovala?
Se parli di C e C++, digita "man gcc" e "man g++" sul terminale.
Per altri linguaggi, riferisciti sempre alla pagina di manuale del compilatore, e eventualmente anche a Google.
Ci tengo a sottolineare che quanto detto da @SpeedJack è molto discutibile.
Certamente, ho specificato all'inizio che può essere utile un IDE per migliorare la produttività. I pro di un IDE sono ovvi e innegabili, ma i contro non sono altrettanto ovvi, però comunque esistono, e ne ho fatto una lista. Poi imho credo che sia meglio non avere proprio a che fare con gli IDE, fanno troppo e nel modo in cui lo hanno pensato gli sviluppatori, meglio un editor di testo con eventualmente dei plugin che si possono caricare dinamicamente e scegliere accuratamente.
Gli IDE sono degli strumenti costruiti dai programmatori per i programmatori, il fatto che li usano anche i pivelli è un altro discorso.
Che siano fatti (inevitabilmente) da programmatori non li rendono migliori. Proprio per evitare di diventare pivelli IDE-dipendenti sostengo che chi deve imparare non deve usare IDE.
perché imparare a memoria gli argomenti da passare a un compilatore quando posso scrivere un software che mi automatizza questo processo?
Non ho detto che non bisogna automatizzare. In fondo i Makefile che fanno? automatizzano la compilazione. La differenza però tra un Makefile e un IDE è che il Makefile devi scriverlo tu, e quindi fa esattamente quello per cui lo hai progettato, mentre l'IDE ha solo dei parametri di default preimpostati, e lancia sempre solo il compilatore con quei parametri. Inoltre un Makefile è molto meno "blackbox" di un IDE: basta un "cat Makefile" per vedere esattamente cosa succede quando si da il comando "make", mentre un IDE tiene molto più nascosto cosa succede quando si clicca su "Compila".
Ma va bene anche utilizzare un IDE per compilare, ma bisogna sempre sapere cosa succede esattamente dietro le quinte quando si preme su "Compila" e bisogna sempre sapere come compilare senza IDE per quando ce ne sarà bisogno.
Perché devo scrivere il noioso codice pieno di coordinate per disegnare l'interfaccia grafica quando posso automatizzare anche questo?
Gli strumenti RAD hanno inevitabilmente dei limiti. Va bene usarli, ma bisogna anche qui sapere esattamente cosa fanno ed essere in grado di scrivere interfacce grafiche direttamente da codice: altrimenti se un giorno lo strumento RAD non basta per fare ciò che si vuole si finisce per progettare interfacce pessime.
nel momento in cui abbiamo davanti un sorgente spezzettato in tanti file, ognuno in una cartella diversa e in gran parte scritto da altre persone, un IDE diventa quasi indispensabile.
Non è assolutamente vero. Basta guardare i progetti open-source: fanno quasi tutti uso dei Makefile ed è pieno di sviluppatori che rifiutano l'uso di IDE e si affidano a editor semplici, con l'eventuale aggiunta di plugin. Un esempio è Linus: usa microemacs e lavora a progetti (Linux, git, subsurface, ecc.) decisamente grandi e spezzettati in tantissimi file. E come lui, tanti altri.
Perché devo fare avanti e indietro tra i files per vedere quali sono i metodi di una classe e i parametri di una funzione, quando qualcuno ha scritto un programma che ti apre un popup con tutte le informazioni che ti possono servire e magari ti reindirizza pure alla documentazione?
Non c'è comunque bisogno di un IDE: ci sono plugin per gli editor o si possono fare script per la shell in grado di farlo. Con la differenza che sono molto più personalizzabili di quello di un IDE. Poi è chiaramente una funzionalità che può tornare spesso utile, e che tutti gli IDE implementano, e bene: è uno strumento utile che non porta effetti collaterali. Ma un IDE è molto di più: è troppo.
Per quanto riguarda il programmatore novizio che sta imparando credo che in fondo anche uno strumento come questo è invece meglio evitarlo: se deve cercarsele manualmente le cose gli restano più impresse e impara di più. Uno strumento che quando digiti "printf" mostra i parametri che accetta e le loro descrizioni e la descrizione della funzione, spiega senz'altro molto meno che andarsi a vedere il codice e i commenti proprio dove la printf è implementata. E si impara di più. (ho fatto un esempio con "printf" ma mi riferisco a qualsiasi funzione scritta da chinque).
Chi impara molto bene è anche in grado di colmare quel dubbio (eg. che argomenti devo passare al compilatore) in poco tempo.
Se uno ha imparato molto bene, appunto, ha imparato. Vuol dire che ha usato e imparato a usare il compilatore da linea di comando. Se un programmatore novizio usa sempre e solo il tasto "Compila" finisce a non sapere nemmeno cos'è un compilatore. Ed ecco perché chi deve imparare non deve usare IDE.
È davvero così indispensabile ricordarsi ogni cavillo sintattico (eg. la definizione del main con i parametri nel C) quando il compito vero dovrebbe essere incentrato sulla semantica?
È quantomeno indispensabile sapere che il main accetta dei parametri e sapere perché li accetta e a cosa servono e come usarli. Chi impara usando IDE e senza mai aver a che fare con la linea di comando può finire anche a non sapere nemmeno che può avviare un programma da terminale passandogli dei parametri.
Ma gli IDE sono pensati per fare esattamente l'opposto, te lo fanno risparmiare il tempo. Per ogni secondo che perdi per un problema proprio dell'IDE, c'è un ora che risparmi. Se non è così allora devi semplicemente cambiare l'IDE perché quello che stai usando è troppo buggato.
Ovviamente: ho soltanto elencato una possibile problematica degli IDE. È più facile che abbia problemi un IDE pieno di componenti e molto complesso che un semplice editor di testo. Poi sicuramente l'IDE accellerà lo sviluppo - ma talvolta capita che l'IDE abbia dei problemi e bisogna accettare di conviverci. Un trade-off sicuramente vantaggioso comunque ma ne va tenuto conto.
Gli strumenti di versioning sono già pensati per risolvere questo tipo di problemi, pensa al .gitignore. Vanno in direzione di standardizzare la directory tree e ormai la maggior parte degli IDE automatizza anche l'uso di questi tools.
Ci sono IDE che inseriscono comandi per "se stessi" all'interno del codice (solitamente in commenti). Non si può usare .gitignore in questi casi (non si può dire a git di ignorare righe specifiche del codice). Questi commenti autogenerati, oltre a sporcare il codice e dar fastidio a chi non usa IDE, possono dar problemi a chi usa lo stesso IDE o IDE diversi che comunque valutano quei commenti.
Ok, è il programmatore a dover far attenzione affinché questa roba non finisca nel repository, ma è un lavoro in più per il programmatore, e una svista può sempre starci (però questa svista può causare problemi che fanno perdere talvolta anche molto tempo).
Se si lavora in team o a progetti open è ben non usare IDE e comunque al massimo strumenti poco invasivi sul codice e sul progetto: è importante aver ben chiaro e visibile cosa verrà caricato sul repository.
se il programmatore è "lo stupido" allora tutto diventa un aspetto negativo, ma se il programmatore è "il programmatore" allora è una feature molto utile.
Ancora: è perciò che un IDE deve tutt'al più utilizzarlo un programmatore già esperto, e non un novizio. Un novizio finisce per accettare i consigli sul codice senza considerare la possibilità che l'IDE non stia consigliando la soluzione ottimale e magari finisce pure per imparare da questi consigli e a ripetere sempre l'approccio consigliato dall'IDE.
Chi è esperto è valuta bene prima di accettare consigli, allora è un altro discorso.
Con il find&replace di un IDE puoi fare cose del tipo cambiare il nome di una variabile senza toccare lo stesso nome fuori dallo scope che stai considerando. Puoi ugualmente fare il search con le regex.
Chi ci dice che sotto il find e replace non ci sia proprio grep e sed?
Al massimo lo strumento dell'IDE può essere potente quanto grep e sed, non di più (grep e sed permettono già di per se praticamente qualsiasi cosa). Considerato poi che grep e sed sono strumento da linea di comando (e non a sola interfaccia grafica come lo strumento dell'IDE) permettono la combinazione con altri programmi e perciò sono, già per questo, inevitabilmente più flessibili dello strumento dell'IDE.
Chi ci dice che l'IDE non ti permetta di avere un mini terminale dal quale lanciare direttamente i comandi?
E a questo punto si esce fuori dall'IDE e si finisce appunto per usare il terminale. Non si sta usando l'IDE in questo caso.
E, se non fosse così, perché non possiamo aprire un terminale, fare i "lavori complessi" con grep, sed e tutto il resto, per poi tornare all'IDE
[...]
Alla fine è uno strumento di automazione e va visto come tale, puoi metterlo momentaneamente da parte se preferisci usare altro.
Certo che si può, e va benissimo: ma bisogna saperlo fare. Chi impara solo a usare l'IDE non saprà mai usare grep, sed e le altre utility. E inoltre, per poterle usare in modo veramente efficiente, bisogna tenersi allenati con esse. Usarli frequentemente o sempre al posto degli strumenti dell'IDE, mantiene allenati.
La negligenza dei programmatori non è da attribuire agli IDE. Se qualcuno è così in gamba da postare cose che non funzionano (per qualsiasi ragione), probabilmente non dovresti interessarti ad usare quella roba.
Questi programmatori così in gamba sono così in gamba spesso proprio perché hanno imparato fin dal principio a usare solo l'IDE. Non rilascerebbero programmi non funzionanti se avessere imparato a programmare fuori dall'IDE.
E questo vale anche nel momento in cui io vengo a metterti sotto le mani un ambiente Windows e addio a bash, coreutils, gcc, gdb e compagnia cantante. Molte di queste cose sono cross platform mi dirai, beh... lo sono anche molti IDE. Tu stesso stai consigliando di passare a Linux, in teoria il sistema operativo (così come l'IDE o text editor che sia) non fa il programmatore.
Yep. Io consiglio a qualsiasi sviluppatore di passare a Linux per diversi aspetti di design del sistema che evitano allo sviluppatore sbattimenti e gli semplificano il lavoro (come "everything is a file" e la predominanza del terminale sull'interfaccia grafica). Poi chiaramente un programmatore veramente completo dovrebbe essere in grado di sviluppare in qualsiasi OS e dovrebbe studiare su tutti (almeno principali). Ma per quanto le cose si fanno per conto proprio o si lavora in progetti open-source o progetti generici non legati a un OS specifico, lavorare da Linux imho aiuta molto lo sviluppatore. Resta il fatto che nel momento che c'è bisogno di usare un altro OS il programmatore deve essere in grado di lavorarci, ma per quando non ci sono esigenze particolari, avere come scelta di "default" Linux secondo me è un'ottima cosa.
Alcune considerazioni le ho fatte anche solo per dare un secondo punto di vista, giusto per far vedere anche l'altro lato della medaglia. A dire il vero io stesso utilizzo un text editor (per una serie di motivi che credo di aver spiegato in un altro thread), però sono consapevole di quali sono i benefici degli IDE ed è per questa ragione nella guida che ho linkato nel post precedente (e che consiglio a tutti di leggere) ho consigliato di partire direttamente da un IDE (uno buono però!). Se si deve imparare qualcosa, tanto vale imparare ciò che si usa nel mondo professionale.
Come ho già detto i vantaggi di un IDE sono innegabili e ovvi. Ma bisogno sempre tenere conto che niente è gratis e i vantaggi degli IDE sono un trade-off: ci sono degli aspetti negativi, che talvolta possono diventare anche pericolosi, in particolar modo per i più inesperti.
Sul consigliare a chi deve imparare di partire direttamente da un IDE invece sono totalmente in disaccordo: prima di tutto è necessario imparare a programmare, non imparare come funzionano le cose nel mondo professionale (che poi, anche nel mondo professionale volendo si può benissimo far a meno degli IDE). Usare un IDE è una cosa che, volendo, deve essere fatta solo dopo. Non quando ancora non si è imparato a programmare.
Per la tua guida: la lessi quando la postai e sì, consiglio anche io a chinque deve iniziare (e quindi all'OP) di leggerla.
Il fatto che alcuni processi siano automatizzati non va assolutamente visto come uno svantaggio, saranno anche automatizzati, ma non vuol dire che non vadano imparati.
È necessario però sapere bene cosa fanno e come. Chi ancora sta imparando non lo sa.
È altrettanto dannoso imparare a memoria memoria i comandi da passare al terminale per fare una qualsiasi cosa. Chi non sa cosa sta facendo, IDE o non IDE, al primo problema che incontra si ritrova bloccato.
Certamente: bisogna sapere sempre cosa si sta facendo. Ma l'IDE tende più a nascondere tutto ciò che sta sotto.


Non c'è niente che gli IDE fanno e che si può ottenere senza IDE. Alla fine, chinque (penso) proveniente da IDE che impara a lavorare senza, dopo un po' non sente minimamente la mancanza dell'IDE. Si può inoltre automatizzare anche al di fuori degli IDE, in modo molto più flessibile e senza alcun "effetto blackbox" che può risultare dannoso.

Per cui: sconsiglio fortemente a chi deve ancora imparare l'uso di IDE. Sconsiglio a questi anche l'uso di editor avanzati come vim che richiedono tanto per imparare (magari, a questi, ci si passa in futuro). Mentre consiglio editor più semplici come gedit. O se qualcuno non riesce a far a meno di qualche comodità ci sono alcuni editor come SublimeText e altri che possiedono molte feature, ma comunque non troppe come un IDE.
Poi, per chi invece è esperto, dovrebbe avere da sé la capacità di scegliere se usare un IDE o no. Ma credo che se ha imparato come deve, senza IDE, poi non sentirà alcuna necessità di alcun IDE. Inoltre anche per gli esperti che usano IDE, è bene che facciano attenzione e si tengano allenati anche su quelle cose che l'IDE automatizza.
 
Stato
Discussione chiusa ad ulteriori risposte.