motivazioni per imparare C

[burohkr]

è un pò di tempo che stò imparando il C ma arrivato ad un certo punto mi sono detto: Cosa faccio? Io voglio fare programmi visuali ma fin ora leggendo vari manuali ho sentito solo di elaborazioni ecc, cioè cose che si possono far girare anche sotto DOS...... ecco perché mi stà passando la voglia. Vi prego di dirmi
da dove traete le vostre motivazioni, per cosa usate il C.....ho veramente voglia di padroneggiarlo ma dopo tutto il tempo che ci ho dedicato vorrei vedere dei risultati da inorgogliosirmi..... Ciao

[recoil]

io detesto scrivere programmi con un'interfaccia utente che non sia il semplice terminale a caratteri!
la vera programmazione non riguarda certo quello che "si vede" ma piuttosto ciò che sta dietro

[maxithron]

Potresti anche integrare la tua conoscenza di C con un ambiente visuale tipo C++.

Per quanto riguarda le motivazioni, beh, possono essercene tante (per quanto mi riguarda almeno).

Ad esempio, quando mi commissionano un software dove è necessario un controllo per il monitoraggio di alcuni fattori(corrente, flusso dati, carico di lavoro, pressioni ,etc...)trovo inutile lavorare con un'interfaccia grafica e,in questo caso, sono pienamente in accordo con recoil.

Altre volte si tratta di applicazioni che richiedono database e quindi archiviazione, di conseguenza il committente ha esigenza di un ambiente visuale su cui poter operare, per cui trovo + semplice lavorare con C++ o addirittura con VB.

Queste citate sono soltanto motivazioni lavorative....per quelle personali attualmente,purtroppo , non dispongo di tempo sufficiente per permettermi di sceglierle

[PGI]

Prova a cercare in rete qualche tutorial sulle api win32 in C.
Ad esempio:

http://sunlightd.virtualave.net/Windows/GUI/ (il primo che ho trovato con google, c'è un esempio su come costruire una finestra in c)

In c/c++ è però decisamente più semplice usare un ambiente di sviluppo che permetta di costruire componenti grafici in modo assistito, come segnalato da maxithron.

Che la vera programmazione sia "ciò che sta dietro" è una rispettabilissima opinione personale, io credo sia un pensiero un po' "retrò".

Anche la linea di comando è una "GUI", per la precisione è la versione più elementare di interfaccia utente che si possa dare, non perchè sia "brutta da vedere" ma perchè permette unicamente l'esecuzione in sequenze "domanda - risposta" (da non confondere con le interfacce a campi di testo, chi ha havuto sottomano un qualsiasi programma di gestione magazzino/contabilità e in genere database per OS400 sa che quelle sono vere e proprie GUI, con l'unica differenza che al posto di bottoni o etichette ci sono dei campi di solo testo).

Anche la progettazione ed implementazione di interfacce utente è vera programmazione, perchè "programmare" significa risolvere problemi, o più correttamente rendere semplice la risoluzione di un problema; le "graphical user interface(s)" sono nate proprio per facilitare (enormemente) l'accesso dell'utente alle routine ("ciò che stà dietro"). Risolvono un problema, e pertanto sono "programmazione" in senso proprio. Per la precisione, la programmazione di interfacce grafiche rappresenta una delle branche della programmazione come "scienza".

Per questo ritengo che sia più che corretta la scelta di burhokr.

Ciao.

[leon84]

Oltre a GUI poi sono sopraggiunte le OOUI .....

E cmq anch'io penso che l'interfaccia grafica giochi un ruolo importantissimo nella realizzazione di un programma ...

[Riverdog]

scusate l'OT,
vorrei solo chiedervi dove posso trovare programmi in C di cui posso vedere il sorgente, a puro scopo didattico, tipo gestione di una biblioteca, videoteca, parcheggio, grazie, è che devo esercitarmi per l'esame di informatica...

Grazie

[mjordan]

Che la vera programmazione sia "ciò che sta dietro" è una rispettabilissima opinione personale, io credo sia un pensiero un po' "retrò".

Ciao.

Il problema è che ha ragione Recoil perchè di un programma la sua interfaccia è la minima parte e, comunque, l'interfaccoia deve muovere tutto ciò che sta dietro (ed è quella la parte complicata, non costruire e assemblare 2 widgets).

Per quanto riguarda il discorso che fai di programmazione GUI come scienza ti sbagli di grosso. Le GUI sono un argomento puramente tecnico. L'unico "problema" da risolvere è come gestirti la GUI del tuo programma. La risoluzione di problemi su COME risolvere un problema si attiene al discorso di scienza che facevi tu. Le GUI hanno problemi puramente tecnici, di fatti ogni problema dipende dal GUI tollkit che usi. Il problema di costruire un albero splay per mantenere una struttura di dati ad eccesso logaritmico è la programmazione come scienza che dicevi tu. Figuriamoci se sono le GUI. Al massimo ti posso dare ragione se usi un approccio a statecharts... Ma dubito...

[mjordan]

Originariamente inviato da leon84
Oltre a GUI poi sono sopraggiunte le OOUI .....

E cmq anch'io penso che l'interfaccia grafica giochi un ruolo importantissimo nella realizzazione di un programma ...

Nessuno affermava il contrario, si diceva che di un programma è comunque una piccolissima parte e per la maggior parte dei software seri è una parte talmente piccola rispetto al codice complessivo che è insignificante imparare un GUI toolkit se poi non si hanno le basi su cosa programmare sotto ...

[gokan]

Originariamente inviato da Riverdog
scusate l'OT,
vorrei solo chiedervi dove posso trovare programmi in C di cui posso vedere il sorgente, a puro scopo didattico, tipo gestione di una biblioteca, videoteca, parcheggio, grazie, è che devo esercitarmi per l'esame di informatica...

Grazie

http://www.dis.uniroma1.it/~progc/indice.html

Su tale libro ci dovrebbe essere roba utile per te. (Io ho lo stesso libro, con esercizi praticamente identici implementati in Pascal).
Ciao

[Riverdog]

Originariamente inviato da gokan
http://www.dis.uniroma1.it/~progc/indice.html

Su tale libro ci dovrebbe essere roba utile per te. (Io ho lo stesso libro, con esercizi praticamente identici implementati in Pascal).
Ciao

Ti ringrazio molto per l'informazione !

Ciao

[mjordan]

Non devi scoraggiarti ma devi capire che se quello che sai è soltanto un linguaggio di programmazione, vuol dire che non hai neanche "cominciato" ....

I linguaggi sono un mezzo per esprimere nei computer la programmazione. Se il linguaggio lo conosci, cosa sai di programmazione?

Ti consiglio vivamente, prima di buttarti nella programmazione GUI (che poi una volta che padroneggi determinati concetti non è neanche difficilissima da imparare) di concentrarti nella risoluzione di problemi semplici ma reali, come ad esempio la creazione di una struttura dati, la sua modifica, costruzione, distruzione e gestione ...Sebbene all'inizio potrebbe sembrarti estremamente complessa, la storia, questo è un argomento che è il primo punto di partenza nella programmazione. Come vedi il linguaggio è solo un mezzo. Ora devi imparare i contenuti da esprimere con questo mezzo. Non c'è niente da scoraggiarsi, è solo la realtà dei fatti.

[leon84]

Originariamente inviato da mjordan
Nessuno affermava il contrario, si diceva che di un programma è comunque una piccolissima parte e per la maggior parte dei software seri è una parte talmente piccola rispetto al codice complessivo che è insignificante imparare un GUI toolkit se poi non si hanno le basi su cosa programmare sotto ...

Si lo so .... ma la seconda parte non era riferita a te ... scusami dovevo essere più preciso ...

[PGI]

Originariamente inviato da mjordan
Il problema è che ...

(quoto tutto ma non lo "riscrivo", sennò viene una post lungo come la barba di mio nonno)

Non concordo, ma è bello vedere opinioni riccamente motivate

Consideriamo tutto quello che segue come incorniciato da un grosso "secondo me", così evito di pontificare.

Forse ci siamo invischiati nel paradosso di Napoleone e del suo esercito, chi fu determinante per le vittorie, l'uno o l'altro? (Nel nostro caso, conta di più il "motore" dell'applicazione o la sua interfaccia?. La virtù stà nel mezzo, si sa, però siamo su un forum, discutiamo )

Sul fatto che le GUI siano questioni tecniche mi sembra ineccepibile, tutto allora sta nel vedere se siano questioni di tecnica-programmazione o di tecnica-grafica;

Forse mi sono espresso ambiguamente, per "problema" non intendo una questione complicata, io intendo lo scopo dell'applicazione. Da questo punto di vista, una struttura dati non è un "problema", è un mezzo o un supporto per giungere allo scopo del programma. Che sia più complicato della costruzione dell'interfaccia è arbitrario: prendiamo un programma di gestione polizze di una società di assicurazioni, l'efficienza del trattamento dei dati pesa parecchio, non è raro che si debbano passare al vaglio parecchie centinaia di miglialia di nodi al giorno e sull'interfaccia..beh, non so se avete mai provato a dire "ma facciamo qualcosa di più user-friendly!"....un'orda di 5000 agenti di assicurazione vi si rivolterà contro . L'interfaccia non è assolutamente un problema, basta "ricalcare" il complesso precedente e "appiccicare" le nuove routine in modo che i bottoni sembrino fare le stesso cose. Per contro, prendete il programma che rilascia i certificati elettronici dell'INPS. Si può pensare che sia una stupidaggine, con 43 milioni di cartelle attive chi vuoi che se ne freghi se l'interfaccia fa schifo. Se ne frega chi lo deve usare, e l'utente "di massa" è supposto, a torto o a ragione, analfabeta in informatica. Non solo, perchè l'INPS possa risparmiare sulla gestione agli sportelli "classici", è assolutamente necessario che l'interfaccia sia efficiente, almeno quanto la gestione dei dati. E non è una questione di bottoni e finestre (ammetto di non sapere cosa sia uno "widget", approssimiamo a "misero componente grafico", il significato non credo cambi); effetti, associazione degli eventi, uso del componente corretto, reazione agli "stimoli", questo fa parte della programmazione di GUI (che, beninteso, è altro rispetto al disegno delle icone sui bottoni ed anche alla scelta dei temi, che considero grafica pura). Stupidaggini? Forse, ma tenete conto che se il processo di stampa non è messo in faccia all'utente esattamente quando dovrebbe aspettarselo, c'è gente che da le testate ai monitor dell'INPS (giuro che l'ho visto).

Ed ora, trucidatemi!

PS. Devo ammettere però che mentre scrivevo un paio di dubbi mi sono venuti...magari li scrivo dopo.

Ciao.

[Pinuz]

scusate se mi intrometto... ma capisco il dubbio... bisogna dire che il C é vecchio.
Cmq il C viene ancora molto utilizzato più che altro per scrivere soft che interagiscono direttamente con l'hardware, pensando che in C é anche possibile inserire codice in ASM, cmq é vero che l'interfaccia grafica di programma a sempre più valore....

[speedwago]

certamente non e' che impari a programmare usando vb interfacciato a un qualsiasi db...al massimo impari a fare le query
saper programmare significa risolvere problemi, ossia trovare algoritmi (si spera efficienti) che fanno al caso nostro.
per trovare algoritmi non servono bottoncini e finestre colorate...serve solo un pezzo di carta!

C'e' qualcuno che dice che il c e' vecchio... io dico che il C per risolvere determinati problemi non e' mai stato usato.
La gestione del parcheggio o ivari "fai le fatture" all'epoca delle "non interfacce grafice" si scrivevano per la granlunga il fortran , cobol o addirittura in pascal!
il C si usa dove sono richieste massima velocita' di esecuzione...
come lo sviluppo di sistemi operativi (il kernel di linux contiene solo 900 linee di assembly...il resto e' c), videogames, calcolo scientifico/distribuito ecc..

i dbms sono cosi' "lenti" che non sara' certo il linguaggio che usi per interfacciarti a fare la differenza... cosa che ha reso gli strumenti ideali vb o java...

[mjordan]

Originariamente inviato da Pinuz
scusate se mi intrometto... ma capisco il dubbio... bisogna dire che il C é vecchio.
Cmq il C viene ancora molto utilizzato più che altro per scrivere soft che interagiscono direttamente con l'hardware, pensando che in C é anche possibile inserire codice in ASM, cmq é vero che l'interfaccia grafica di programma a sempre più valore....

Bhè adesso non mi sembra il caso di sollevare questioni che non c'entrano nulla ... Sappi solo che la maggior parte del software di sistema sul pianeta è scritta in C ed anche una grande maggioranza di programmi applicativi. Tutti i nuclei dei sistemi operativi attualmente sul pianeta sono scritti in C. E se non ti basta anche Return to Castle Wolfenstein e Quake III Arena sono scritti in C.

[mjordan]

Originariamente inviato da PGI
(quoto tutto ma non lo "riscrivo", sennò viene una post lungo come la barba di mio nonno)

Non concordo, ma è bello vedere opinioni riccamente motivate

Consideriamo tutto quello che segue come incorniciato da un grosso "secondo me", così evito di pontificare.

Forse ci siamo invischiati nel paradosso di Napoleone e del suo esercito, chi fu determinante per le vittorie, l'uno o l'altro? (Nel nostro caso, conta di più il "motore" dell'applicazione o la sua interfaccia?. La virtù stà nel mezzo, si sa, però siamo su un forum, discutiamo )

Sul fatto che le GUI siano questioni tecniche mi sembra ineccepibile, tutto allora sta nel vedere se siano questioni di tecnica-programmazione o di tecnica-grafica;

Forse mi sono espresso ambiguamente, per "problema" non intendo una questione complicata, io intendo lo scopo dell'applicazione. Da questo punto di vista, una struttura dati non è un "problema", è un mezzo o un supporto per giungere allo scopo del programma. Che sia più complicato della costruzione dell'interfaccia è arbitrario: prendiamo un programma di gestione polizze di una società di assicurazioni, l'efficienza del trattamento dei dati pesa parecchio, non è raro che si debbano passare al vaglio parecchie centinaia di miglialia di nodi al giorno e sull'interfaccia..beh, non so se avete mai provato a dire "ma facciamo qualcosa di più user-friendly!"....un'orda di 5000 agenti di assicurazione vi si rivolterà contro . L'interfaccia non è assolutamente un problema, basta "ricalcare" il complesso precedente e "appiccicare" le nuove routine in modo che i bottoni sembrino fare le stesso cose. Per contro, prendete il programma che rilascia i certificati elettronici dell'INPS. Si può pensare che sia una stupidaggine, con 43 milioni di cartelle attive chi vuoi che se ne freghi se l'interfaccia fa schifo. Se ne frega chi lo deve usare, e l'utente "di massa" è supposto, a torto o a ragione, analfabeta in informatica. Non solo, perchè l'INPS possa risparmiare sulla gestione agli sportelli "classici", è assolutamente necessario che l'interfaccia sia efficiente, almeno quanto la gestione dei dati. E non è una questione di bottoni e finestre (ammetto di non sapere cosa sia uno "widget", approssimiamo a "misero componente grafico", il significato non credo cambi); effetti, associazione degli eventi, uso del componente corretto, reazione agli "stimoli", questo fa parte della programmazione di GUI (che, beninteso, è altro rispetto al disegno delle icone sui bottoni ed anche alla scelta dei temi, che considero grafica pura). Stupidaggini? Forse, ma tenete conto che se il processo di stampa non è messo in faccia all'utente esattamente quando dovrebbe aspettarselo, c'è gente che da le testate ai monitor dell'INPS (giuro che l'ho visto).

Ed ora, trucidatemi!

PS. Devo ammettere però che mentre scrivevo un paio di dubbi mi sono venuti...magari li scrivo dopo.

Ciao.

Scusa ma non ho capito una mazza di quello che volevi dire, comunque sappi che una struttura dati è un mezzo solo quando è fine a se stessa. In un problema reale, in un software reale, le strutture dati sono il nucleo dell'architettura di un software, quindi sono un problema vero e proprio. Se poi mi chiarisci in parole povere tutto quello che volevi dire col tuo monologo mi fai un piacere

[burohkr]

Mi sembra di capire che devo cominciare dalle GUI..... oppure partire con il C++...........l'importante è che non mi passi la voglia di imparare perché questo problema mi ha sempre afflitto, comincio ma poi non finisco perché non sono soddisfatto dei risultati.

[mjordan]

Originariamente inviato da burohkr
Mi sembra di capire che devo cominciare dalle GUI..... oppure partire con il C++...........l'importante è che non mi passi la voglia di imparare perché questo problema mi ha sempre afflitto, comincio ma poi non finisco perché non sono soddisfatto dei risultati.

Hai capito male ...
Ti devi imparare a risolvere i problemi. Che sai fare un bottone e poi a quel bottone non gli sai far fare niente non serve a nulla.

[PGI]

Originariamente inviato da mjordan
...una struttura dati è un mezzo solo quando è fine a se stessa. In un problema reale, in un software reale, le strutture dati sono il nucleo dell'architettura di un software, quindi sono un problema vero e proprio. Se poi mi chiarisci in parole povere tutto quello che volevi dire col tuo monologo mi fai un piacere

Lo sapevo, ho pontificato. "Pardon"

Ho il sospetto vago che stiamo parlando di due cose diverse.

Quando dici che le strutture dati sono un "problema", intendi dire che la struttura dati è lo scopo dell'applicazione? (parliamo di applicazioni reali e non di esercizi). Direi di no.

Per struttura=mezzo, io intendevo dire che il modello per la gestione dei dati non è lo scopo del programma ma una delle questioni da risolvere per arrivare ad un programma funzionale, al pari dell'interfaccia.

Che siano il nucleo dell'architettura dipende poi da cosa intendi per nucleo (personalmente ho sempre ritenuto arbitraria la divisione del software in nucleo e sovrastruttura).

Originariamente inviato da burohkr Mi sembra di capire che devo cominciare dalle GUI..... oppure partire con il C++...........l'importante è che non mi passi la voglia di imparare perché questo problema mi ha sempre afflitto, comincio ma poi non finisco perché non sono soddisfatto dei risultati.

Comunque si risolva la "diatriba" sulle GUI, è vero che dovresti concentrarti di più sulle funzioni "nude e crude" perchè se è vero (in teoria) che puoi programmare senza interfacce funzionali non è vero il contrario (l'esempio del bottone di mjordan calza).

Benchè le librerie C (ad esempio quelle per windows) non siano le più maneggevoli nel panorama dei linguaggi, non è detto che sia necessario passare a C++ (che da questo punto di vista non sta certo meglio).

Ciao.