motivazioni per imparare C

[recoil]

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.

[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

[bsummer]

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

[cionci]

Originariamente inviato da bsummer
Quindi, prendiamo un bel motore e poi facciamoci sopra una bella linea

Giusto !!!

[mjordan]

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?

[mjordan]

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.

[maxithron]

In sostanza.....:

[mjordan]

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!

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]

In sostanza...:

[mjordan]

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.

[maxithron]

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.

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?

[mjordan]

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]

appunto....era quello che volevo far notare per tornare alla questione del titolo del 3d.

[maxithron]

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!!

[mjordan]

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

[maxithron]

Nulla...nulla...appena puoi mi offri una birra

[mjordan]

Originariamente inviato da maxithron
Nulla...nulla...appena puoi mi offri una birra

Ok

[cionci]

Mi aggrego alla birretta...non c'entro niente nel discorso, ma quando si parla di birra il mio fegato irlandese prende il sopravvento !!!

[a2000]

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 !

[cionci]

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)...