Ma come si programma ?

[Thunderfox]

Ciao a tutti, ho un problema che non riesco a risolvere, ovvero non riesco a capire come si fa a programmare...

Il problema è che ho provato ad iniziare con diversi linguaggi di programmazione, ma una volta letti i tutorial o le guide e una volta che ho imparato a stampare del testo sullo schermo (il classico hello world) e ad effettuare operazioni matematiche, ecc... , poi mi blocco...

Non riesco a capire cosa posso fare con tutto quello che ho imparato, visto che poi quando vado ad eseguire quello che ho scritto, mi ritrovo con una squallida finestra dos

Per di più gli esempi che vengono proposti in quasi tutti i linguaggi di programmazione mi sembrano tutti privi di utilità.

Io vorrei programmare e avere come risultato dei veri e propri programmi che possono girare sotto windows (quindi con un minimo di grafica).

Come faccio ad applicare tutto quello che ho imparato, per creare programmi per windows ?
Premetto che ho acquistato un libro sul c++ ma alla fine gli esempi che vengono proposti, si basando sempre su programmi che si eseguono in finestre dos.

Help, di voglia di imparare ne ho tanta, ma sono in una fase di stallo.

Datemi qualche consiglio

[mastoo]

purtroppo per imparare a programmare la console è necessaria almeno all'inizio.
Se gia sai programmare abbastanza ti consiglio di utilizzare un ambiente RAD(Rapid application development) per programmare tipo delphi, con qualche guida gia puoi fare qualche programma piu divertente
buon lavoro

[mapomapo]

i linguaggi come il C o il C++ sono tutti testuali..ci vogliono le librerie visual per far quello che dici tu...
oppure puoi imparare a programmare in php...

Vito

[vizzz]

se ti senti pronto buttati sul visual c++
http://www.microsoft.com/italy/msdn/...wnload/vc.mspx

[dierre]

il fatto è che a livelli un pò più seri è tutto codice e poca grafica. Nel senso che in quei "programmi per windows" di cui tu parli, la grafica rappresenta solo la rappresentazione dei dati, niente di più. Questo per dirti che prima stabilisci cosa fare, il come lo vuoi rappresentare è un problema secondario. Cmq sia puoi usare per esempio visual c++ che offre un modo molto facilitato di fare programmi visuali.

[skintek1]

io direi anche visual basic....cmq i veri programmi si scrivono.......

[PGI-Bis]

Quando serve i programmi bisogna anche disegnarli.

[skintek1]

non la penso cosi'....

[alberto.frz]

Io ti consiglio il di partire dal C. Le basi che impari ti faranno un bel bagaglio...poi prova tranquillamente linguaggi tipo visual c++ o visual basic cosi ti diverti anche un po' con la grafica.

L'unica cosa veramente importante è che bisogna

saluti (a tutti)

[vizzz]

Originariamente inviato da PGI-Bis

Quando serve i programmi bisogna anche disegnarli.

esatto...oltre al design di un programma per quanto riguarda classi e strutture dati...c'è anche il design della gui...e un visual studio che integra un editor bell'e pronto benvenga.

[giannola]

Originariamente inviato da Thunderfox

Ciao a tutti, ho un problema che non riesco a risolvere, ovvero non riesco a capire come si fa a programmare...

Il problema è che ho provato ad iniziare con diversi linguaggi di programmazione, ma una volta letti i tutorial o le guide e una volta che ho imparato a stampare del testo sullo schermo (il classico hello world) e ad effettuare operazioni matematiche, ecc... , poi mi blocco...

Non riesco a capire cosa posso fare con tutto quello che ho imparato, visto che poi quando vado ad eseguire quello che ho scritto, mi ritrovo con una squallida finestra dos

Per di più gli esempi che vengono proposti in quasi tutti i linguaggi di programmazione mi sembrano tutti privi di utilità.

Io vorrei programmare e avere come risultato dei veri e propri programmi che possono girare sotto windows (quindi con un minimo di grafica).

Come faccio ad applicare tutto quello che ho imparato, per creare programmi per windows ?
Premetto che ho acquistato un libro sul c++ ma alla fine gli esempi che vengono proposti, si basando sempre su programmi che si eseguono in finestre dos.

Help, di voglia di imparare ne ho tanta, ma sono in una fase di stallo.

Datemi qualche consiglio

tu soffri della classica sindrome di "mancanza di obiettivo", ovvero assimili le regole di programmazione ma poi non sai come metterle insieme semplicemente perchè non ti sei posto un obiettivo, ovvero un programma da realizzare.
Saper programmare non è tutto bisogna anche sapere fare una analisi di ciò che si vuole realizzare e come implementarlo.

Supponi ad esempio di volere fare una rubrica telefonica dunque devi innanzitutto raccogliere dei dati e memorizzarli, poi dovrai anche visualizzarli magari attraverso una ricerca.

In genere si parte da una idea e poi ci si domanda come svilupparla, una volta che si ha uno schema allora si può iniziare a programmare.
Finchè non ti sarai dato un obiettivo (comincia da qualcosa di semplice) non imparerai mai a programmare.

[giannola]

Originariamente inviato da dierre

il fatto è che a livelli un pò più seri è tutto codice e poca grafica. Nel senso che in quei "programmi per windows" di cui tu parli, la grafica rappresenta solo la rappresentazione dei dati, niente di più. Questo per dirti che prima stabilisci cosa fare, il come lo vuoi rappresentare è un problema secondario. Cmq sia puoi usare per esempio visual c++ che offre un modo molto facilitato di fare programmi visuali.

questo è un approccio infondato.
Se ci si basa sulla programmazione ad oggetti l'orientamento grafico per rappresentare gli stessi è il passo necessario per programmare efficentemente.
Gli oggetti non sono materia inerte da programmare ma sono entità con attributi e metodi propri i quali al limite possono essere ulteriormente implementati e non necessariamente sono contenitori di dati ma realizzano funzioni complesse.
Se si dovesse scrivere tutto il codice necessario per non usare gli oggetti a disposizione in pratica si finirebbe molto, ma molto più tardi.

[dierre]

Originariamente inviato da giannola

questo è un approccio infondato.
Se ci si basa sulla programmazione ad oggetti l'orientamento grafico per rappresentare gli stessi è il passo necessario per programmare efficentemente.
Gli oggetti non sono materia inerte da programmare ma sono entità con attributi e metodi propri i quali al limite possono essere ulteriormente implementati e non necessariamente sono contenitori di dati ma realizzano funzioni complesse.
Se si dovesse scrivere tutto il codice necessario per non usare gli oggetti a disposizione in pratica si finirebbe molto, ma molto più tardi.

Non ho capito che c'entra con quello che stavo dicendo io. Io non ho parlato di programmazione oggetti. Intendevo dire che devi prima porti un obiettivo, progettarlo (ad oggetti o come ti pare) e poi di preoccuparti della parte visuale. Se non sai cosa fa il tuo programma è inutile che progetti le i bottoni e le finestre, per farla breve.

[71104]

Originariamente inviato da Thunderfox

Io vorrei programmare e avere come risultato dei veri e propri programmi che possono girare sotto windows (quindi con un minimo di grafica).

se vuoi imparare a programmare specificamente per Windows esiste la libreria MSDN, ovvero la documentazione ufficiale di Microsoft sulla programmazione Windows. MSDN contiene tutto lo scibile (ovvero tutto ciò che ci è dato sapere) su Windows. questo è l'URL dell'indice principale in MSDN sulla programmazione Win32 (la sezione però in realtà include anche il DDK, che serve a programmare drivers per Windows): http://msdn2.microsoft.com/en-us/library/aa139672.aspx

per consultare MSDN ovviamente è richiesta una buona conoscenza di C e C++. inoltre per quando programmi su Windows ti consiglio di utilizzare Microsoft Visual Studio 2005 in edizione Express, oppure Enterprise se sei uno studente universitario e alla tua università hanno MSDNAA.

se proverai a fare qualche esperimento di applicazione grafica in Windows utilizzando le funzioni Win32 ti accorgerai molto presto che utilizzare direttamente Win32 è un lavoro molto oneroso per un programmatore, e siccome per un programmatore "lavoro oneroso" significa "lavoro error-prone" ti chiederai se non esistano set di funzioni/classi per C/C++ già pronti che ti semplifichino le cose permettendoti ad esempio ti assolvere compiti molto comuni senza dover riscrivere ogni volta una dozzina di chiamate Win32 con relativi controlli sul codice di errore ritornato. la risposta è si tali set si chiamano "frameworks" ed uno che io trovo assolutamente ottimo è wxWidgets.

[giannola]

Originariamente inviato da dierre

Non ho capito che c'entra con quello che stavo dicendo io. Io non ho parlato di programmazione oggetti. Intendevo dire che devi prima porti un obiettivo, progettarlo (ad oggetti o come ti pare) e poi di preoccuparti della parte visuale. Se non sai cosa fa il tuo programma è inutile che progetti le i bottoni e le finestre, per farla breve.

allora ho capito male, adesso somiglia tanto al mio primo post

[Thunderfox]

Originariamente inviato da giannola

tu soffri della classica sindrome di "mancanza di obiettivo", ovvero assimili le regole di programmazione ma poi non sai come metterle insieme semplicemente perchè non ti sei posto un obiettivo, ovvero un programma da realizzare.
Saper programmare non è tutto bisogna anche sapere fare una analisi di ciò che si vuole realizzare e come implementarlo.

Supponi ad esempio di volere fare una rubrica telefonica dunque devi innanzitutto raccogliere dei dati e memorizzarli, poi dovrai anche visualizzarli magari attraverso una ricerca.

In genere si parte da una idea e poi ci si domanda come svilupparla, una volta che si ha uno schema allora si può iniziare a programmare.
Finchè non ti sarai dato un obiettivo (comincia da qualcosa di semplice) non imparerai mai a programmare.

Bravo hai centrato in pieno il mio problema.
Sia in c++ che in python avevo provato a fare una rubrica, con tanto di menù per aggiungere voci, cancellarle, ecc...
Però l'esecuzione avveniva sempre tramite console di windows.

Avrei voluto fare la stessa cosa ma in una finestra di windows, purtroppo non so come legare il codice alla grafica.

Cmq grazie delle risposte e dei consigli, avete risposto veramente in tanti

Forse prenderò in considerazione il visual c++.

[71104]

Originariamente inviato da Thunderfox

Forse prenderò in considerazione il visual c++.

bravo :P

e scarica la versione 2005 :P

[jappilas]

Originariamente inviato da Thunderfox

<....>
Avrei voluto fare la stessa cosa ma in una finestra di windows, purtroppo non so come legare il codice alla grafica.
<....>

oh, bene - cioè, abbiano trovato il primo "obiettivo"

a questo punto, come prima cosa direi che dovresti cercare di "visualizzare" l' aspetto che dovrebbe avere la tua applicazione (magari con uno schizzo su carta): questo per identificare quali widget o "controlli" (liste, campi di testo, griglie, finestre grafiche eccetera... ) saranno necessari nel tuo programma, e farti un' idea del "flusso" operativo che l' interfaccia esporrà: ora per una rubrica questo passaggio sarà abbastanza semplice ...

una volta determinata la struttura della parte visiva della tua applicazione, è da valutare quale toolkit library usare per implementarla - tenendo conto che ognuna ha una propria API, proprie particolarità e idiosincrasie , e quindi modalità d' uso differenti ...
scelto un toolkit, è da acquisire la sua API, quantomeno per ciò che concerne il o i widget di cui hai bisogno, e le problematiche e necessità di quel toolkit a livello generale ( ad es, routine di inizializzazione comuni a tutta la libreria, modello d' uso, convenzioni eccetera ): quindi , anche se pensavi di saper programmare, dovrai rimetterti a studiare perchè un conto è il linguaggio, un conto sono le funzioni di libreria ...

Inoltre tieni conto che i "widget", quelli integrati in una libreria (come può essere MFC, GTK, QT), come quelli che magari svilupperai tu o magari comprerai (come ho scoperto leggendo msdn magazine, decine di società campano vendendo "controlli" aggiuntivi e activeX, alcuni davvero belli e sofisticati ) per sopperire alle necessità di una tua applicazione - spesso e volentieri NON operano direttamente sui dati del l working set dell' applicazione, ma su un subset costruito per la presentazione e l' interazione

Anche se può apparire banale, questo dovrebbe farti intuire che nel tuo programma andranno implementate in modo appropriato le chiamate per l' inizializzazione dei widget presenti, quelle per l' aggiornamento (modifica della struttura dati in memoria -> aggiornamento del contenuto della finestra, caso banale pressione di "CANC" in una lista con un elemento selezionato) e i punti in cui il tuo codice reagisce a condizioni notificate DAL widget o come le notifica AL widget : in pratica "legare il codice alla grafica" è l' ultimo passo...

è vero che in un ambiente RAD con i wizard per creare nuovi metodi nella tua classe, o nuovi progetti basati su template tra cui magari applicazioni centrate su quella certa GUI library, o per abbinare un certo messaggio a un metodo ... questo è molto semplificato
ma comunque presuppone la conoscenza del significato di un certo messaggio notificato, o della funzione di una certa callback o... , a questo serviva il passaggio precedente (studio della API e delle particolarità della libreria , conoscenza che comunque acquisirai una tantum per una determinata combinazione "OS /famiglia di OS" - toolkit e spesso potrai riutilizzare )
E comunque tieni conto che anche i wizard inseriscono sezioni di codice nei file del tuo progetto, quindi in effetti come diceva qualcuno, "è sempre codice" ...

[mindwings]

Originariamente inviato da jappilas

oh, bene - cioè, abbiano trovato il primo "obiettivo"

a questo punto, come prima cosa direi che dovresti cercare di "visualizzare" l' aspetto che dovrebbe avere la tua applicazione (magari con uno schizzo su carta): questo per identificare quali widget o "controlli" (liste, campi di testo, griglie, finestre grafiche eccetera... ) saranno necessari nel tuo programma, e farti un' idea del "flusso" operativo che l' interfaccia esporrà: ora per una rubrica questo passaggio sarà abbastanza semplice ...

una volta determinata la struttura della parte visiva della tua applicazione, è da valutare quale toolkit library usare per implementarla - tenendo conto che ognuna ha una propria API, proprie particolarità e idiosincrasie , e quindi modalità d' uso differenti ...
scelto un toolkit, è da acquisire la sua API, quantomeno per ciò che concerne il o i widget di cui hai bisogno, e le problematiche e necessità di quel toolkit a livello generale ( ad es, routine di inizializzazione comuni a tutta la libreria, modello d' uso, convenzioni eccetera ): quindi , anche se pensavi di saper programmare, dovrai rimetterti a studiare perchè un conto è il linguaggio, un conto sono le funzioni di libreria ...

Inoltre tieni conto che i "widget", quelli integrati in una libreria (come può essere MFC, GTK, QT), come quelli che magari svilupperai tu o magari comprerai (come ho scoperto leggendo msdn magazine, decine di società campano vendendo "controlli" aggiuntivi e activeX ) per sopperire alle necessità di una tua applicazione - spesso e volentieri NON operano direttamente sui dati del l working set dell' applicazione, ma su un subset costruito per la presentazione e l' interazione

Anche se può apparire banale, questo dovrebbe farti intuire che nel tuo programma andranno implementate in modo appropriato le chiamate per l' inizializzazione dei widget presenti, quelle per l' aggiornamento (modifica della struttura dati in memoria -> aggiornamento del contenuto della finestra, caso banale pressione di "CANC" in una lista con un elemento selezionato) e i punti in cui il tuo codice reagisce a condizioni notificate DAL widget o come le notifica AL widget : in pratica "legare il codice alla grafica" è l' ultimo passo...

è vero che in un ambiente RAD con i wizard per creare nuovi metodi nella tua classe, o nuovi progetti basati su template tra cui magari applicazioni centrate su quella certa GUI library, o per abbinare un certo messaggio a un metodo ... questo è molto semplificato
ma comunque presuppone la conoscenza del significato di un certo messaggio notificato, o della funzione di una certa callback o... , a questo serviva il passaggio precedente (studio della API e delle particolarità della libreria , conoscenza che comunque acquisirai una tantum per una determinata combinazione "OS /famiglia di OS" - toolkit e spesso potrai riutilizzare )
E comunque tieni conto che anche i wizard inseriscono sezioni di codice nei file del tuo progetto, quindi in effetti come diceva qualcuno, "è sempre codice" ...

dopo questo intervento non credo che abbia idee chiare come prima

secondo me dovresti imparare a programmare per il web
quello che cerchi è la concretezza e sviluppare un programma
ti potrebbe portare via molto tempo prima di vedere dei risultati
accettabili. mentre vedere anche del codice html scritto in maniera corretta
può dare più soddisfazione e voglia di continuare a programmare / imparare

[71104]

Originariamente inviato da mindwings

dopo questo intervento non credo che abbia idee chiare come prima

secondo me dovresti imparare a programmare per il web
quello che cerchi è la concretezza e sviluppare un programma
ti potrebbe portare via molto tempo prima di vedere dei risultati
accettabili. mentre vedere anche del codice html scritto in maniera corretta
può dare più soddisfazione e voglia di continuare a programmare / imparare

allora forse gli volevi consigliare di programmare in Java o in .NET, non in HTML