View Full Version : motivazioni per imparare C
è 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
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
21-08-2003, 11:55
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:( :( :(
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.
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
21-08-2003, 19:54
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:)
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...
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 ...
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
21-08-2003, 22:13
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
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.
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 ... ;)
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 :D
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 :D . 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! :D
PS. Devo ammettere però che mentre scrivevo un paio di dubbi mi sono venuti...magari li scrivo dopo.
Ciao.
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
22-08-2003, 03:12
certamente non e' che impari a programmare usando vb interfacciato a un qualsiasi db...al massimo impari a fare le query :D
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...
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.
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 :D
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 :D . 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! :D
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 :D
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.
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 ... :D
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.
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 :D
Lo sapevo, ho pontificato. "Pardon" :D
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.
beh ragazzi diciamo una cosa: qualcuni delle GUI si dovrà pure occupare!
però non è progettando applicazioni visuali che si diventa un buon programmatore.
il visual basic è stato quasi agli inizi per me e credevo di cavarmela bene ma in realtà non facevo altro che usare degli oggetti già pronti per fare operazioni banali.
mi si passi il termine: chi fa le GUI è un "muratore" dell'informatica. io preferisco di gran lunga essere un architetto.
Io credo che dipenda da ciò che si deve programmare...
Se si programma un word processor o un programma di disegno (tanto per fare un paio di esempi) l'interfaccia è fondamentale per il buon successo dell'applicativo...
Credo che nell'80-90% degli applicativi il problema + grande non sia l'interfaccia, bensì il "motore" del programma...
In questi casi è meglio sapere prima programmare il "motore" del nostro software e dopo l'interfaccia...ed è per questo che il C ti sarà sicuramente utile... Inoltre il saper programmare non è un problema di C, C++, Java o Pascal, ma è il saper raggiungere una soluzione efficiente per il problema, qualunque sia il linguaggio...
L'interfaccia viene dopo ed ha il solo scopo di rendere il "motore" utilizzabile in maniera migliore, cercando di catturare l'interesse degli utenti con i vari "fronzoli" ;)
Ciò non toglie che sia una componente importante !!!
Ti sconsiglio di passare subito ad un linguaggio con framework grafico perchè molte volte ti allontana dallo scopo per cui stai studiando un linguaggio di programmazione...cioè imparare a programmare ;)
Sono sostanzialmente daccordo con Cionci, tuttavia non si può negare come negli ultimi anni le interfacce gafiche abbia giocato un ruolo sempre più importante nel mondo dell'informatica.
Pensate che in facoltà da me c'è un corso chiamato "Interazione Uomo-Macchina" interamente votato allo studio delle interfacce (tra le quali la maggior parte sono grafiche).
Tuttavia con i toolkit presenti nel mercato oggi, il problema del programmatore non è tanto "creare l'interfaccia" (in quanto i componenti sono già tutti disponibili) ma renderla intuitiva e rapida all'uso seguendo determinate regole.
Una bella macchina non cammina se sotto non c'è un motore che la spinge, mentre una macchina che fa schifo non se la compra nessuno anche se fila che è un piacere.
Quindi, prendiamo un bel motore e poi facciamoci sopra una bella linea ;)
Originariamente inviato da bsummer
Quindi, prendiamo un bel motore e poi facciamoci sopra una bella linea ;)
Giusto !!! :)
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.
Non è lo scopo dell'applicazione. E' un mezzo dinamico con cui si progetta il funzionamento di un'applicazione. Ed è il mezzo + importante. Tutti gli algoritmi e in generale le funzioni che si implementeranno POI sono influenzate da come sono state progettate le strutture di dati. Cosa che non si verifica, in buona parte con le GUI. Se scrivo una routine che elabora una matrice, posso adattarla senza sforzo ad un qualsiasi "bottone", sia esso GTK+ o Motif, ma non posso fare lo stesso per farlo funzionare con una lista, almeno senza cambiare completamente il "senso" dell'algoritmo.
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.
Non sono d'accordo. Un programma non funziona perchè ha un'interfaccia. L'interfaccia serve per CONTROLLARE le modalità di funzionamento di un software. Non puoi paragonare interfaccia/struttura dati allo stesso livello. L'interfaccia influenza molto poco come le routine interne debbano essere scritte, le strutture dati influenzano la quasi totalità del codice prodotto all'interno dell'applicazione.
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).
Per nucleo intendo ciò che si intende. Componenti centrali di un'architettura. Le fondamenta di un'architettura. Il fatto dell'arbitrarietà di una divisione architetturale di componenti è ovvia. Tutto dipende da scelte progettuali.
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).
Ma allora tutto sto discorso a che è servito? :D
Originariamente inviato da cionci
Io credo che dipenda da ciò che si deve programmare...
Se si programma un word processor o un programma di disegno (tanto per fare un paio di esempi) l'interfaccia è fondamentale per il buon successo dell'applicativo...
Credo che nell'80-90% degli applicativi il problema + grande non sia l'interfaccia, bensì il "motore" del programma...
In questi casi è meglio sapere prima programmare il "motore" del nostro software e dopo l'interfaccia...ed è per questo che il C ti sarà sicuramente utile... Inoltre il saper programmare non è un problema di C, C++, Java o Pascal, ma è il saper raggiungere una soluzione efficiente per il problema, qualunque sia il linguaggio...
L'interfaccia viene dopo ed ha il solo scopo di rendere il "motore" utilizzabile in maniera migliore, cercando di catturare l'interesse degli utenti con i vari "fronzoli" ;)
Ciò non toglie che sia una componente importante !!!
Ti sconsiglio di passare subito ad un linguaggio con framework grafico perchè molte volte ti allontana dallo scopo per cui stai studiando un linguaggio di programmazione...cioè imparare a programmare ;)
Grazie Cionci, hai espresso in maniera impeccabile quello che volevo dire dire senza evidentemente farmi capire. :muro:
maxithron
23-08-2003, 17:30
In sostanza.....:
Pensate che in facoltà da me c'è un corso chiamato "Interazione Uomo-Macchina" interamente votato allo studio delle interfacce (tra le quali la maggior parte sono grafiche).
A me si chiama interfacce uomo-macchina! :confused:
Quindi, prendiamo un bel motore e poi facciamoci sopra una bella linea ;)
Sono d'accordo, però siamo un po usciti dal tema originale. Non stiamo parlando di importanza dell'uno su un altro, quanto di saper appunto saper realizzare prima un "motore" e solo poi farci una "linea".
maxithron
23-08-2003, 17:31
In sostanza...:
Originariamente inviato da maxithron
In sostanza.....:
E' un modo scherzoso di dire che i veri programmatori conoscono l'assembly, ovvero conoscono l'architettura sottostante.
Forse era anche una metafora per dire che i "veri programmatori" conoscono quello che stanno programmando. :D
maxithron
23-08-2003, 17:51
Originariamente inviato da mjordan
E' un modo scherzoso di dire che i veri programmatori conoscono l'assembly, ovvero conoscono l'architettura sottostante.
Forse era anche una metafora per dire che i "veri programmatori" conoscono quello che stanno programmando. :D
Sicuramente.....
Sono però anche del parere che vi sia un approccio sbagliato da parte di chi adopera l'uso di ambienti visuali affidando tutto al classico wizard.
Come dicevo qualche post + su, (ed è sempre un parere personale), non esiste per me IL LINGUAGGIO di programmazione in senso assoluto(mi auto quoto):
che dire..... l'ideale sarebbe conoscerli tutti e a fondo per poi scegliere quelli che + si adattano alla nostra inventiva ma.....
Originariamente inviato da maxithron
Molte volte anch'io sono stato tentato di abbandonare linguaggi "semplici" per quelli più complessi ma mi sono sempre chiesto:
1) con questo linguaggio sono arrivato al limite del linguaggio?
2) oppure con questo linguaggio sono arrivato al limite della mia conoscenza di questo linguaggio?
Originariamente inviato da maxithron
Sicuramente.....
Sono però anche del parere che vi sia un approccio sbagliato da parte di chi adopera l'uso di ambienti visuali affidando tutto al classico wizard.
Come dicevo qualche post + su, (ed è sempre un parere personale), non esiste per me IL LINGUAGGIO di programmazione in senso assoluto(mi auto quoto):
che dire..... l'ideale sarebbe conoscerli tutti e a fondo per poi scegliere quelli che + si adattano alla nostra inventiva ma.....
Ti dico solo che oggi tutti i problemi possono essere espressi in C. Direi quindi che sei arrivato al limite delle tue conoscenze, non del linguaggio che non c'entra nulla ...
maxithron
23-08-2003, 18:09
appunto....era quello che volevo far notare per tornare alla questione del titolo del 3d.
maxithron
23-08-2003, 18:11
E questa era la risposta che davo in quell'altro 3d che conferma che sono in accordo con te:
Originariamente inviato da maxithron
chi si illude che la risposta esatta sia la prima....beh, ha ancora tanto da sgobbare!!
Originariamente inviato da maxithron
E questa era la risposta che davo in quell'altro 3d che conferma che sono in accordo con te:
Scusa, mi ero perso un pezzo :D
maxithron
23-08-2003, 18:19
Nulla...nulla...appena puoi mi offri una birra:cincin:
Originariamente inviato da maxithron
Nulla...nulla...appena puoi mi offri una birra:cincin:
Ok :mano: :ubriachi:
Mi aggrego alla birretta...non c'entro niente nel discorso, ma quando si parla di birra il mio fegato irlandese prende il sopravvento !!!:ubriachi: :Puke:
Originariamente inviato da 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
hai ragione.
d'altra parte potevi insospettirti per tempo: si chiama C come Cesso !
:p
Originariamente inviato da a2000
d'altra parte potevi insospettirti per tempo: si chiama C come Cesso !
Ricordati che senza il C non potresti programmare in Frotran (visto che il sistema operativo sul quale programmi è fatto al 90% in C, parlo di qualsiasi sistema operativo commerciale)...
e infatti nessuno nega che la Tazza del Cesso sia un attrezzo indispensabile :)
Originariamente inviato da cionci
Ricordati che senza il C non potresti programmare in Frotran (visto che il sistema operativo sul quale programmi è fatto al 90% in C, parlo di qualsiasi sistema operativo commerciale)...
In effetti da quando mi sono affacciato al mondo della programmazione mi è sempre stato detto che C fosse il linguaggio per eccellenza ....
Ma credo però che la sua potenza lo porti ad essere spesso uno dei linguaggi più rompiscatole ....
Sei d'accordo con me cionci ???
Originariamente inviato da 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
io uso BCB e ti assicuro che nonostante tutto il vero programma da te sviluppato è quello che non si vede;)
maxithron
24-08-2003, 09:39
Originariamente inviato da cionci
Mi aggrego alla birretta...non c'entro niente nel discorso, ma quando si parla di birra il mio fegato irlandese prende il sopravvento !!!:ubriachi: :Puke:
[OT]
Beh...prima o poi questo benedetto incontro tra gli utenti di questa sezione del forum dovremo pure organizzarlo
:) :) :) a quando?
Originariamente inviato da bsummer
Pensate che in facoltà da me c'è un corso chiamato "Interazione Uomo-Macchina" interamente votato allo studio delle interfacce (tra le quali la maggior parte sono grafiche).
ah si c'è anche da noi a Milano.
in realtà ho seguito un altro corso in cui si parlava di interfacce utente e si faceva il paragone con gli oggetti del mondo reale (ad esempio una maniglia deve essere intuitiva da spingere/tirare) e di quanto fosse importante la sua semplicità e facilità d'uso.
non credo cmq che qualcuno abbia sottovalutato l'importanza della componente grafica di un'applicazione, quello che io ho detto è "ci pensi qualcun altro" e quello che dicono altri è: se vuoi imparare a programmare NON partire dalla GUI
Originariamente inviato da maxithron
[OT]
Beh...prima o poi questo benedetto incontro tra gli utenti di questa sezione del forum dovremo pure organizzarlo
:) :) :) a quando?
SMAU?
approfittando dell'evento di hwupgrade e della tanta gente che di sicuro ci sarà
Originariamente inviato da recoil
....
non credo cmq che qualcuno abbia sottovalutato l'importanza della componente grafica di un'applicazione, quello che io ho detto è "ci pensi qualcun altro" e quello che dicono altri è: se vuoi imparare a programmare NON partire dalla GUI
MA SGUSA SE NON BARDIAMO DA GUI ALLORA NON BARDIAMO BROBRIO :confused:
Originariamente inviato da a2000
MA SGUSA SE NON BARDIAMO DA GUI ALLORA NON BARDIAMO BROBRIO :confused:
Se rileggi i thread precedenti forse evitiamo di ricominciare con la discussione :D
Tornando al discorso delle interfacce senza "motore" ecco cosa succede quando si "sa" scrivere un'interfaccia ma non un "motore" :D :D :D
http://forum.hwupgrade.it/showthread.php?threadid=500213
Originariamente inviato da a2000
hai ragione.
d'altra parte potevi insospettirti per tempo: si chiama C come Cesso !
:p
Ma ke minkiate vai dicendo... Ma per piacere ... :ncomment:
Originariamente inviato da mjordan
Tornando al discorso delle interfacce senza "motore" ecco cosa succede quando si "sa" scrivere un'interfaccia ma non un "motore" :D :D :D
http://forum.hwupgrade.it/showthread.php?threadid=500213
azz ma lo prendi per il culo pesantemente vedo :rotfl:
Originariamente inviato da recoil
azz ma lo prendi per il culo pesantemente vedo :rotfl:
Se avesse detto il giusto, non mi sarei divertito così... Ma è bonaria la cosa
:D :D :D
Originariamente inviato da mjordan
Ma ke minkiate vai dicendo... Ma per piacere ... :ncomment:
hai ragione non C come Cesso ma C come minChiata.
come sapevano i latini, c'è la ragione profonda delle cose nei nomi:
Il C è il linguaggio di Sturmtruppen: non a caso ha l'elmetto austroungarico come emblema sintattico {} e non a caso il propalatore della sua versione più Cervellotica si chiama Stroustrup che come tutti gli Strounztrup finirà nel Cesso.
dai miogiordano nun't'nCazza'
:)
A parte gli scherzi...si chiama C perchè è il diretto successore di un linguaggio che si chiamava...B.
Nè + nè -.
Aloha!
Originariamente inviato da bsummer
A parte gli scherzi...si chiama C perchè è il diretto successore di un linguaggio che si chiamava...B.
Nè + nè -.
Aloha!
che migliorava il BCPL ;)
TonyManero
17-10-2003, 14:02
Aggiungo che la conoscenza del C ha sbocchi anche nell'ambito dei Microcontrollori a 16bit. ;)
Quindi impiego come firmwarista/progettista. :)
Ciao.
Originariamente inviato da TonyManero
Aggiungo che la conoscenza del C ha sbocchi anche nell'ambito dei Microcontrollori a 16bit. ;)
Quindi impiego come firmwarista/progettista. :)
Ciao.
Bastasse solo la conoscenza del C. . .
TonyManero
17-10-2003, 15:08
Serve un po' una conoscenza amplia... ma che si può benissimo fare sul campo. ;)
Io ho cominciato che sapevo solo il C. L'architettura dei micro, l'uso degli oscilloscopi digitali e strumentazioni varie e la conoscenza di base dell'hardware me le sono tutte costruite lavorando. :)
Beato a te che ti hanno assunto facendoti lavorare mentre ti "costruivi" ;)
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.