View Full Version : Mi sto per iscrivere ad ing. informatica:consigli
Sono un appassionato di computer e volevo sapere come mi troverò con tale laurea nel settore lavorativo.Ero anche interessato ad ingegneria edile-architettura ma non sono molto portato per il disegno.Voi che mi consigliate? Faccio bene ad iscrivermi ad ingegneria informatica visto che segue la mia passione?
Grazie per i consigli.
Il programma è questo:
Sono un appassionato di computer e volevo sapere come mi troverò con tale laurea nel settore lavorativo.Ero anche interessato ad ingegneria edile-architettura ma non sono molto portato per il disegno.Voi che mi consigliate? Faccio bene ad iscrivermi ad ingegneria informatica visto che segue la mia passione?
Grazie per i consigli.
Il programma è questo:
:eek:
scappa finchè sei in tempo ragazzo!!!!
:eek:
scappa finchè sei in tempo ragazzo!!!!
da ingegnere, non posso che quotare.
NON LO FARE! ti pentirai, come mi sono pentito io.
E ci sto male
bravoragazzo
23-09-2005, 13:48
da ingegnere, non posso che quotare.
NON LO FARE! ti pentirai, come mi sono pentito io.
E ci sto male
sicuro che sei ingegnere?
sicuro che non hai avuto grosse delusioni?
di solito così lo dicono coloro che non ce l'hanno fatta o ce l'hanno fatta a stento :p
Scoperchiatore
23-09-2005, 14:47
E' una facoltà non troppo difficile, studi cose interessanti, se ti piace il mondo dell'informatica e il progettare, tutto sommato è una facoltà decente.
Tieni presente che non impari a programmare, ma a risolvere problemi legati al mondo dell'informatica.
Se studi per passione ti troverai bene. Se studi perchè "poi guadagno tanto", ti troverai male e avrai brutte delusioni.
Il settore informatico è in crisi nera, ed è difficile trovare un lavoro anche non da ingegnere; in Italia la figura dell'ingegnere informatico non è considerata quasi per nulla, e difatti difficilmente fai un lavoro adatto ai tuoi studi. Spesso vieni riciclato in altro modo.
bravoragazzo
23-09-2005, 15:06
ma una laurea in ing informatica è vero che risulta mediamente piu' facile di una laurea in ing meccanica o elettronica?
ing elettronica è da urlo :mc:
sicuro che sei ingegnere?
sicuro che non hai avuto grosse delusioni?
di solito così lo dicono coloro che non ce l'hanno fatta o ce l'hanno fatta a stento :p
sulla parete di casa ho un attestato dell'Universita' di Pavia che dice di essermi alureato il 24 marzo 2000, penso, quindi, di essere ingegnere :)
inoltre ho sostwnuto con successo l'esame di stato nel luglio 2000, quiindi penso di essere ingnegnere.
Perche' sono deluso? perche' lavoro da oltre 5 anni in R&D di una multinazionale e prendo 200 euro in piu' di un'autista di autobus con la terza media
Scoperchiatore
23-09-2005, 15:45
ma una laurea in ing informatica è vero che risulta mediamente piu' facile di una laurea in ing meccanica o elettronica?
ing elettronica è da urlo :mc:
Elettronica è poco più difficile, ma se ti piace, direi che il livello di difficoltà è comparabile.
Meccanica IMHO è la più difficile, seguita da edile. Informatica, fra le ingegnerie "classiche" è forse la più semplice.
bravoragazzo
23-09-2005, 15:45
sulla parete di casa ho un attestato dell'Universita' di Pavia che dice di essermi alureato il 24 marzo 2000, penso, quindi, di essere ingegnere :)
inoltre ho sostwnuto con successo l'esame di stato nel luglio 2000, quiindi penso di essere ingnegnere.
Perche' sono deluso? perche' lavoro da oltre 5 anni in R&D di una multinazionale e prendo 200 euro in piu' di un'autista di autobus con la terza media
se non fossi laureato ti rimpiangeresti addosso di non esserti laureato (sai quante persone conosco che dicono così?).
bravoragazzo
23-09-2005, 15:48
Elettronica è poco più difficile, ma se ti piace, direi che il livello di difficoltà è comparabile.
Meccanica IMHO è la più difficile, seguita da edile. Informatica, fra le ingegnerie "classiche" è forse la più semplice.
guarda che nella mia univ parecchi falliti ad elettronica sono passati a meccanica... :sofico:
in genere nelle ingegnerie della classe ''industriale'' c'è sempre un livello piu' basso...
Tieni presente che non impari a programmare, ma a risolvere problemi legati al mondo dell'informatica.
Questa affermazione la limiterei al tuo ambito o comunque alle persone che si limitano a studiare ciò che serve per l'esame. Ing Inf ti dà la base e lo spunto per ulteriori approfondimenti personali. Mica ci si può aspettare la pappa pronta in tutto. Ti dà gli strumenti per poter fare una ricerca su google e capire in 10 minuti l'uso di un costrutto o una libreria di cui avevi mai sentito parlare prima.
E' certo vero che rispetto a corsi tecnici di Informatica, insegna meno a programmare, ma ti consiglio altrove solo se come mestiere vuoi fare il programmatore a tempo pieno.
Scoperchiatore
23-09-2005, 17:12
Questa affermazione la limiterei al tuo ambito o comunque alle persone che si limitano a studiare ciò che serve per l'esame. Ing Inf ti dà la base e lo spunto per ulteriori approfondimenti personali. Mica ci si può aspettare la pappa pronta in tutto. Ti dà gli strumenti per poter fare una ricerca su google e capire in 10 minuti l'uso di un costrutto o una libreria di cui avevi mai sentito parlare prima.
E' certo vero che rispetto a corsi tecnici di Informatica, insegna meno a programmare, ma ti consiglio altrove solo se come mestiere vuoi fare il programmatore a tempo pieno.
Guarda che diciamo la stessa cosa.
consigli? iscriviti ad ing meccanica
sono pronto ad accettare la sfida
escludo tutti gli altri corsi poichè già visti e non mi piacciono a parte ingegneria edile ma non ho fatto il test d'ingresso per cui ciccia :sofico:
inutile dire che lo faccio per il titolo non certo perchè voglio guadagnare so che c'è crisi nel settore anche se guardando il programma al 80% contiene materie che mi piacciono (a parte elettronica che proprio non la digerisco dite che è un male? :confused: )
Abadir_82
24-09-2005, 00:23
per pierpo. Non vorrei dire cavolate, ma per essere ingegneri è necessario superare l'esame di stato. Il pezzo di carta dice solo che sei dottore in ingegneria... :D
per pierpo. Non vorrei dire cavolate, ma per essere ingegneri è necessario superare l'esame di stato. Il pezzo di carta dice solo che sei dottore in ingegneria... :D
infatti, come ho scritto, ho sostenuto pure l'esame di stato :D
mpattera
25-09-2005, 12:12
Tieni presente che non impari a programmare, ma a risolvere problemi legati al mondo dell'informatica.
quoto, le basi della programmazione le ho imparate alle superiori e approfondite per conto mio..all'uni in un corso di tre mesi sul c (che comunque è un corso a basso livello) non impari niente.
ps: preparati a studiare un sacco di matematica.
quoto, le basi della programmazione le ho imparate alle superiori e approfondite per conto mio..all'uni in un corso di tre mesi sul c (che comunque è un corso a basso livello) non impari niente.
ps: preparati a studiare un sacco di matematica.
Questa è la dimostrazione che non tute le ing inf sono uguali! :D
Da noi si fanno ANNI di C++, poi Java, Assembler didattico e non, Verilog, UML, PHP, HTML, CORBA IDL, SQL4, e accenni vari. La matematica invece, per fortuna, è molto più limitata rispetto ad un corso di informatica "pura".
Scoperchiatore
25-09-2005, 23:21
Questa è la dimostrazione che non tute le ing inf sono uguali! :D
Da noi si fanno ANNI di C++, poi Java, Assembler didattico e non, Verilog, UML, PHP, HTML, CORBA IDL, SQL4, e accenni vari. La matematica invece, per fortuna, è molto più limitata rispetto ad un corso di informatica "pura".
mi spiace... :D
da come la descrivi sembra una laurea improntata al pratico che tende ad escludere molto il teorico: io non ne sarei stato contento.
Cmq, anche io anche ho fatto Java e C, assembler l'ho evitato per scelta mia.
SQL ovviamente si fa, ma non è un linguaggio di programmazione: stesso dicasi di HTML, che mi pare anche inutile fare (che c'è da capire???). UML è utile, ma anche lui è veramente poca cosa.
Corba e Verilog non ho idea di che siano, però conosco Prolog e la famiglia ML.
C++ non l'ho mai fatto, da noi fanno solo Java. E personalmente lo preferisco, mi sembra più pulito e più high level, ma questi sono gusti.
Al posto di PHP abbiamo fatto JSP e J2EE, decisamente più divertenti :cool:
Io ho studiato concetti, non cose che posso leggere sul manuale. PHP non l'ho mai studiato all'uni, impararlo da solo è stata questione di... 3 ore?
Mi sono appassionato a questo mondo conoscendo la matematica e la logica di Ethernet, le idee alla base TCP, le macchine di Turing, strutture e algoritmi cazzuti, design patterns, principio di induzione applicato dimostrazione di correttezza di algoritmi complessi, struttura dei sistemi operativi, DBMS e via dicendo. Tutte queste cose sono matematica in altre forme...
Se mi togliessero la matematica e la logica, mi chiederei perchè sto andando all'uni, quando potrei capire tutto leggendolo da un libro.
Ovviamente so bene che anche tu hai trattato tutte queste cose approfondendo la matematica di base e ovviamente la logica, ma sembri bistrattarla, almeno dal tono del tuo ultimo post.
Un ingegnere, IMHO, rimane sempre inferiore ad un informatico, per quanto riguarda la programmazione: ed è anche giusto, un elettrauto sa di macchine e di loro meccanica, ma sicuramente di meno di un meccanico (se ovviamente sono tutti e due bravi e preparati).
Credo che il motivo per cui si chiami "ingegneria" informatica sia propio perchè alla fine dei 5 anni non sei una macchinetta che sa fare le cose a comando, ma un qualcuno che sa riconoscere problemi simili in contesti differenti, applicare soluzioni vecchie a problemi nuovi, rielaborare concetti e comprenderne di nuovi, e, semmai esista ancora qualcuno pagato per farlo, inventare cose nuove.
Se non guadagnassi queste capacità non avrebbe senso chiamarla Ingegneria: sarebbe meglio "Corso di computer molto avanzato".
Non voglio bistrattare la matematica: di fatto non l'ho scritto. Ho scritto solo che non da tutte le parti si fa così tanta matematica, ed il mio caso ne è la dimostrazione. Dopo tutto cmq, esiste il corso di Informatica (Pura) che nacque a suo tempo proprio come branca della matematica, e che tutt'oggi ne è potentemente pervasa. Esiste poi Ingegneria che invece cura aspetti diversi, altrimenti che senso avrebbe chiamare una Ingegneria e l'altra no?
L'elenco dei linguaggi di programmazione era solo per dire che non è vero che si fanno solo poche cosette, ed il resto te lo devi vedere per conto tuo, dipende tanto dal caso. Personalmente, senza offesa, una Ingegneria Informatica che insegna solo C e Java, mi pare un po' la facoltà dei puffi. Poi certo, sono pareri. Non si può, secondo me, non conoscere il C++ che, proprio perché di alto livello "basso", permette di realizzare con praticità cose che il Java si sogna. Per non parlare del bellissimo Assembler che permette cose che in altri linguaggi non è complesso, ma fisicamente -impossibile- realizzare. Detto questo Ing Inf non forma programmatori, per quello bastano dei corsi specializzati, anche al di là della laurea. Forma figure professionali delle più varie che però non possono prescindere dalla programmazione, anche se vuoi fare il sistemista o il tecnico di rete. Troppa matematica o logica, alla fine, sono ottimi mezzi per scrivere libri, non necessariamente per svolgere bene il proprio lavoro di Ingegnere. Bada bene, non voglio scatenare flame, dico soltanto che alla fine, se devi progettare un software devi conoscere bene il concetto di Ingegneria del Software, che abbraccia la logica in fase di analisi dei requisiti e di stesura delle specifiche del sistema, ma la cosa finisce poi là in tempo relativamente breve. Il resto si basa tutto su progetto (UML è un linguaggio di progetto universale), creazione delle interfacce (il CORBA IDL serve allo scopo), all'implementazione dei moduli (C++ la fa da padrone in molti sistemi, Java in altri, ma più o meno sono quelli [io preferisco C++] ), al test di unità, di integrazione, di sistema, di verifica, di convalida ecc ecc... insomma, conoscere qualche cosetta in più aiuta anche a portare il pane a casa.
Anche coloro che prediligono l'hardware, non possono abbandonare il C/C++/Assembler, soprattutto se devono aver a che fare con sistemi Linux o comunque con lo sviluppo di drivers.
Questa metodicità non la impari né con soli libri, che con tre ore di impegno. Io sinceramente trovo un fine in ciò che faccio anche senza eccesso di matematica o logica, anche perché se avessi avuto tanta passione per queste due discipline, mi sarei iscritto al CdL in Matematica, probabilmente. :)
E poi credo che alcune doti debbano essere naturali se scegli un certo percorso di studio, senza dover perderci più di quel tempo nella loro formalizzazione in sede universitaria. Se poi uno prende la via della specialistica+dottorato, e si appassiona all'aspetto più astratto della cosa bene, ma prima penserei al necessario.
Ripeto, tutto IMHO, non voglio criticare nessuno.
Scoperchiatore
26-09-2005, 00:27
Non voglio bistrattare la matematica: di fatto non l'ho scritto. Ho scritto solo che non da tutte le parti si fa così tanta matematica, ed il mio caso ne è la dimostrazione. Dopo tutto cmq, esiste il corso di Informatica (Pura) che nacque a suo tempo proprio come branca della matematica, e che tutt'oggi ne è potentemente pervasa. Esiste poi Ingegneria che invece cura aspetti diversi, altrimenti che senso avrebbe chiamare una Ingegneria e l'altra no?
Sono d'accordo col tuo discorso, pur considerando la matematica la base del mio "lavoro" (studio ancora...)
[....]
Ripeto, tutto IMHO, non voglio criticare nessuno.
Sono sostanzialmente d'accordo con il tuo discorso, a parte il discorso su C++, che ho studiato leggendo DP della gang of four, e l'ho trovato identico a Java (a livello concettuale). Credo che le potenzialità dei due siano identiche, ma per la sua documentazione standard Java è secondo me un passo avanti: ovviamente perde in prestazioni, è troppo lento per molte applicazioni pratiche (guarda matlab 7 che con l'interfaccia in Java è diventato un polmone, o DB2, che ha addirittura il core in java, e ciò lo rende di un'inefficienza unica).Anche sull'assembler ho i miei dubbi: serve se pensi di dover programmare a basso livello, almeno IMHO, ma altrove ha poca valenza (soprattutto quello didattico: sei uno dei pochissimi fortunati in Italia ad aver fatto il non didattico!)
Ritengo molto più utile aver studiato un linguaggio funzionale (tu ne hai fatto qualcuno?), che mi ha permesso di apprezzare questo tipo di programmazione, che è, secondo me, la più elegante in assoluto: quando ti bastano 3 righe di codice (pulito e comprensibilissimo) per visitare un albero e 4 per un grafo, guardi il tuo programma così: :cool: :D
Ricordo che il problema delle 8 regine lo risolsi in Ocaml scrivendo "ben" 8 righe di codice (una era forzata perchè c'ho messo una eccezione che mi potevo evitare :D) :cool:
Per me un linguaggio funzionale è satana :D
No davvero, io preferisco un linguaggio ad alto livello a con costrutti assimilabili alle istruzioni assembler che ci stanno sotto. Un compito simpatico che abbiamo trattato è stato proprio la traduzione da C++ (con puntatori, classi, chiamate di funzioni parametriche e tutte le incasinature del caso) ad Assembler. Ecco, da quel magico momento in poi vedo un listato C++ in modo molto più chiaro di 8 righe di codice, forse perché so esattamente ciò che fa, non lascia nulla di magico o per caso, insomma, ho il pieno controllo della cosa.
Riguardo alla differenza C++/Java ce ne sono parecchie, come parecchie limitazioni del Java. Una banale che mi capita per la mente è l'assenza di ereditarietà multipla propriamente detta del Java. Non che ci sbatta la testa tutti i giorni, ma se ti capita di averne bisogno e non poterne disponere...
Riguardo alle prestazioni poi ti sei già risposto da solo: non c'è minimamente paragone :)
Edit: se ti piace un codice parecchio pulito, intuibile, è sufficiente crearsi le interfacce in maniera ottima, con nomi di funzione esplicativi, #inlcludere il tutto nel file sorgente su cui lavori e magicamente 8 righe C++ sembrano uguali a quelle di un qualsiasi linguaggio "funzionale", pur essendo C++ puro. Io preferisco sempre questo approccio.
Io ho studiato concetti, non cose che posso leggere sul manuale. PHP non l'ho mai studiato all'uni, impararlo da solo è stata questione di... 3 ore?
Mi sono appassionato a questo mondo conoscendo la matematica e la logica di Ethernet, le idee alla base TCP, le macchine di Turing, strutture e algoritmi cazzuti, design patterns, principio di induzione applicato dimostrazione di correttezza di algoritmi complessi, struttura dei sistemi operativi, DBMS e via dicendo. Tutte queste cose sono matematica in altre forme...
Se mi togliessero la matematica e la logica, mi chiederei perchè sto andando all'uni, quando potrei capire tutto leggendolo da un libro.
Sono tutti corsi argomenti ampiamente trattati anche nel corso di laurea in informatica, assieme a tutta la teria della clalcolabilità, algoritmi paralleli, IA, teoria dell'informazione.
Un ingegnere, IMHO, rimane sempre inferiore ad un informatico, per quanto riguarda la programmazione: ed è anche giusto, un elettrauto sa di macchine e di loro meccanica, ma sicuramente di meno di un meccanico (se ovviamente sono tutti e due bravi e preparati).
Credo che il motivo per cui si chiami "ingegneria" informatica sia propio perchè alla fine dei 5 anni non sei una macchinetta che sa fare le cose a comando, ma un qualcuno che sa riconoscere problemi simili in contesti differenti, applicare soluzioni vecchie a problemi nuovi, rielaborare concetti e comprenderne di nuovi, e, semmai esista ancora qualcuno pagato per farlo, inventare cose nuove.
Se non guadagnassi queste capacità non avrebbe senso chiamarla Ingegneria
Le stesse competenze sono proprie del corso di laurea in informatica, non nè una prerogativa di ingeneria; sbagliate se continuate a credere che da ingneria informatica esce chi deve risolvere i problemi o trovare nuove soluzioni e da informatica il programmatore. La programmazione che si fa ad informatica è generalmente UN PO' di più di quella che si fa ad ingegneria e la differenza sta più che altro in alcuni esami piu legati all'elettronica e all'hardware in ingegneria, sostituiti ad informatica da esami piu orientati al software. Non c'entra la capacità di saper risolvere problemi o di avere solide basi teoriche. Tra l'altro è informatica che appartiene alla facoltà di scienze matematiche, quindi semmai sarebbe ingeneria ad avere una finalità piu direttamente pratica e applicativa.
Scoperchiatore
26-09-2005, 20:41
Per me un linguaggio funzionale è satana :D
No davvero, io preferisco un linguaggio ad alto livello a con costrutti assimilabili alle istruzioni assembler che ci stanno sotto. Un compito simpatico che abbiamo trattato è stato proprio la traduzione da C++ (con puntatori, classi, chiamate di funzioni parametriche e tutte le incasinature del caso) ad Assembler. Ecco, da quel magico momento in poi vedo un listato C++ in modo molto più chiaro di 8 righe di codice, forse perché so esattamente ciò che fa, non lascia nulla di magico o per caso, insomma, ho il pieno controllo della cosa.
Si, io l'ho fatto con C per studiare l'attacco buffer overflow, e devo dire che è una cosa che adesso consiglio a molti: ti fa rendere conto in modo perfetto di quel che fa il tuo linguaggio
Riguardo alla differenza C++/Java ce ne sono parecchie, come parecchie limitazioni del Java. Una banale che mi capita per la mente è l'assenza di ereditarietà multipla propriamente detta del Java. Non che ci sbatta la testa tutti i giorni, ma se ti capita di averne bisogno e non poterne disponere...
Riguardo alle prestazioni poi ti sei già risposto da solo: non c'è minimamente paragone :)
Basta fare interfaccie al posto di classi astratte, le potenzialità del linguaggio sono le stesse (ma questo è ovvio, sono grammatiche di tipo 2 che permettono di esprimere una qualunque grammatica di tipo 0) ;)
Quella che dal tuo punto di vista è una limitazione, dal punto di vista della teoria della progettazione software, è uno stimolo a progettare le cose in modo più accurato: è facile, anche troppo, usare a sproposito il concetto di classe astratta, soprattutto se sai che una classe può rendere concreta più classi astratte. In questo modo rischi di diminuire la coesione, e sparpagliare il comportamento di un oggetto in varie parti del codice.
Se invece sai che la classe astratta è un "jolly" e lo devi usare solo quando sei più che certo che il concetto logico che vuoi modellare richiede una specializzazione di un concetto più generale, la usi con cautela e parsimonia. Prova ne è che nelle API di Java si usano quasi esclusivamente interfacce: anche i programmatori "bravi" che fanno quelle API, non si azzardano ad usare troppo il concetto di ereditarietà, anche soltanto singola.
Edit: se ti piace un codice parecchio pulito, intuibile, è sufficiente crearsi le interfacce in maniera ottima, con nomi di funzione esplicativi, #inlcludere il tutto nel file sorgente su cui lavori e magicamente 8 righe C++ sembrano uguali a quelle di un qualsiasi linguaggio "funzionale", pur essendo C++ puro. Io preferisco sempre questo approccio.
Non hai capito che intendevo ;)
Usando Java sono abituato a fare package, e a limitare i metodi a 5-6 righe, è uno stile di programmazione abbastanza diffuso: includi 3-4 librerie, fai metodi corti e sintetici, e il codice è pulito. Ma è un sotterfugio, sai bene che quella classe, dopo che il precompilatore ha svolto il lavoro di inclusione, è lunga almeno 30-40 righe. Con un linguaggio funzionale, non hai bisogno di altro: 8 righe, a inclusione completata, per un problema NP completo come quello del covering (n-regine).
Ma un linguaggio funzionale è altro: già solo nella dichiarazione di tipo, che prevede un dominio (ovvio) e un CODOMINIO, hai definito un mondo. L'eleganza della tipizzazione estrema, della matematica pura nei linguaggi funzionali, Java, C e Pascal se la sognano. I linguaggi funzionali hanno 1 solo operatore, e nessuna struttura di controllo: eppure ci fai tutto, in estrema sintesi. Quando leggo un programma serio scritto in Ocaml, dico: è arte :D
Sia chiaro, non uso più Ocaml da una vita :D però averlo studiato è stata forse la cosa più sorprendente che mi è capitato di studiare nel corso di studi, insieme alla teoria della calcolabilità e alla struttura di TCP (che non avrei mai immaginato così complesso!)
Scoperchiatore
26-09-2005, 20:46
Sono tutti corsi argomenti ampiamente trattati anche nel corso di laurea in informatica, assieme a tutta la teria della clalcolabilità, algoritmi paralleli, IA, teoria dell'informazione.
Le stesse competenze sono proprie del corso di laurea in informatica, non nè una prerogativa di ingeneria; sbagliate se continuate a credere che da ingneria informatica esce chi deve risolvere i problemi o trovare nuove soluzioni e da informatica il programmatore. La programmazione che si fa ad informatica è generalmente UN PO' di più di quella che si fa ad ingegneria e la differenza sta più che altro in alcuni esami piu legati all'elettronica e all'hardware in ingegneria, sostituiti ad informatica da esami piu orientati al software. Non c'entra la capacità di saper risolvere problemi o di avere solide basi teoriche. Tra l'altro è informatica che appartiene alla facoltà di scienze matematiche, quindi semmai sarebbe ingeneria ad avere una finalità piu direttamente pratica e applicativa.
Si, ma guarda che si parlava solo di ingegneria, senza cercare il confronto. Fra le due figure esiste una differenza piccola, e nessuno può dire in "favore" dell'ingegnere o del dottore. Dipende tantissimo dai posti in cui si è studiato.
Come hai sottolinetao, è l'ingegnere quello più applicativo (tutto in teoria, lasciamo perdere ciò che poi succede nel mondo del lavoro), e quindi lui risolve i problemi, nel senso che "fa" qualcosa (che sia un algoritmo, una riduzione, un firmware, un qualunque cosa).
Il matematico informatico dovrebbe più distaccarsi dalla pratica. Ma poi succede mai questa cosa?
Io sono dell'idea che, oggi come oggi, non v'è differenza palpabile fra le due figure professionali. Il posto in cui si è studiato è forse l'unica tangibile differenza fra neolaureati di tutte le materie che hanno a che fare con informatica.
bravoragazzo
26-09-2005, 21:48
forse ingegneria informatica è un pizzichino + facile di informatica. questo perché ad informatica si fanno progetti di programmi abbastanza complessi... cose che nn si fanno a ingegneria dove con la ''scusa'' di fare esami elettronici ecc si perde l'essenza della laurea.
l'ing informatico non è ne' ing elettronico ne' programmatore. alla fine oltre alla solita fuffa che sa risolvere problemi (davvero? chi ce lo garantisce?) sa fare veramente poco rispetto ad un informatico appassionato di programmazione che ti sforna programmi in 2 ore
Non hai capito che intendevo ;)
Usando Java sono abituato a fare package, e a limitare i metodi a 5-6 righe, è uno stile di programmazione abbastanza diffuso: includi 3-4 librerie, fai metodi corti e sintetici, e il codice è pulito. Ma è un sotterfugio, sai bene che quella classe, dopo che il precompilatore ha svolto il lavoro di inclusione, è lunga almeno 30-40 righe. Con un linguaggio funzionale, non hai bisogno di altro: 8 righe, a inclusione completata, per un problema NP completo come quello del covering (n-regine).
Ho capito benissimo, di fatto ti ho scritto anche la motivazione.
Un linguaggio di questo tipo sara bello quanto ti pare a vedersi, ma il processore se ne sbatte la palle della bellezza, scusa la franchezza. :D
Io da Ingegnere, se vedessi un collega che predilige un linguaggio per la sua pulizia del codice, del tutto (o parzialmente) ignaro di come il compilatore traduce il tutto, con quali corrispondenze, controlli e ottimizzazioni, non lo guarderei certo al mio pari. Non mi sembra certo modo per garantire ottimizzazione di alcun tipo. Dopotutto il codice sorgente deve essere leggibile (carattere fondamentale della qualità del software), ma non banale. Aggiungici poi che qualsiasi linguaggio compilato, alla fin fine, scende a livello di istruzioni assembler, il vantaggio di un linguaggio funzionale è apparente. Se un ragazzino delle medie mi dice che non ci capisce nulla, nei miei listati, non ci rimango certo male né penso di aver svolto male il mio lavoro.
Per questo motivo l'approccio modulare (approccio principe di quasi qualsiasi ingegneria del software) non è uno stratagemma per fingere un codice pulito, ma un ottimo modo per organizzare qualcosa che di pulito ha davvero poco, ovvero il ragionamento di una macchina. :)
Allora ragazzi domani vado a consegnare i moduli per l'immatricolazione: ormai ho deciso. Ero interessato anche ad informatica pura ma dovevo per forza cambiare regione e non me lo posso permettere economicamente.
Scoperchiatore
26-09-2005, 23:23
forse ingegneria informatica è un pizzichino + facile di informatica. questo perché ad informatica si fanno progetti di programmi abbastanza complessi... cose che nn si fanno a ingegneria dove con la ''scusa'' di fare esami elettronici ecc si perde l'essenza della laurea.
l'ing informatico non è ne' ing elettronico ne' programmatore. alla fine oltre alla solita fuffa che sa risolvere problemi (davvero? chi ce lo garantisce?) sa fare veramente poco rispetto ad un informatico appassionato di programmazione che ti sforna programmi in 2 ore
Non sono per nulla d'accordo.
E' per questo motivo che ci sono tanti programmi che fanno vomitare, perchè sono scritti in 2 ore. Chiunque sa scrivere qualcosa di funzionante in 2 ore, pochissimi sanno fare qualcosa di buono in 2 ore, nessuno in 2 ore scriverà codice che non ritoccherà qualche giorno dopo.
E la differenza di base è che l'ing o informatico questo lo sa. E sa anche, forse cosa più importante, i limiti della sua materia: ho molti dubbi che un ragazzino che programma per passione sappia capire se un problema è riducibile alle corrispondenze di Post e quindi irrisolvibile.
Se poi uno non sa risolvere probemi dopo la laurea, forse non ha capito un cazzo, forse non era tagliato, forse non ha studiato abbastanza. Fatto sta che di norma non dovrebbe essere così.
Scoperchiatore
26-09-2005, 23:45
Ho capito benissimo, di fatto ti ho scritto anche la motivazione.
Un linguaggio di questo tipo sara bello quanto ti pare a vedersi, ma il processore se ne sbatte la palle della bellezza, scusa la franchezza. :D
Io da Ingegnere, se vedessi un collega che predilige un linguaggio per la sua pulizia del codice, del tutto (o parzialmente) ignaro di come il compilatore traduce il tutto, con quali corrispondenze, controlli e ottimizzazioni, non lo guarderei certo al mio pari. Non mi sembra certo modo per garantire ottimizzazione di alcun tipo.
Tu generalizzi un po troppo. Le prestazioni non sono importanti in moltissimi ambiti. A prescindere da questo, se consideri che i costi di manutenzione del codice sono il 50% delle spese complessive, ti rendi ben conto che, linguaggio a oggetti, funzionale o imperativo, scrivere codice brutto o troppo conciso (come spesso si faceva in C) è una delle peggiori abitudini dei programmatori.
Quindi la scelta fra ottimizzazione e chiarezza è sempre difficile, e va pensata caso per caso.
Dopotutto il codice sorgente deve essere leggibile (carattere fondamentale della qualità del software), ma non banale.
Questo dipende dall'ambito di programmazione. Non sempre una bella cosa deve essere complessa.
Aggiungici poi che qualsiasi linguaggio compilato, alla fin fine, scende a livello di istruzioni assembler, il vantaggio di un linguaggio funzionale è apparente. Se un ragazzino delle medie mi dice che non ci capisce nulla, nei miei listati, non ci rimango certo male né penso di aver svolto male il mio lavoro.
Per questo motivo l'approccio modulare (approccio principe di quasi qualsiasi ingegneria del software) non è uno stratagemma per fingere un codice pulito, ma un ottimo modo per organizzare qualcosa che di pulito ha davvero poco, ovvero il ragionamento di una macchina. :)
L'approccio funzionale ha il grandissimo vantaggio di permettere la dimostrazione di correttezza dei programmi.
Come ben sai, non è possibile dimostrare la correttezza di un algoritmo a meno che non lo si provi per tutti gli infiniti input, oppure non si riesca tramite il principio di induzione a dimostrare matematicamente che non potrà mai sbagliare. Dato che la prima strada non è percorribile, l'unica altra possibilità è una dimostrazione matematica, che in un linguaggio iterativo è difficilmente intraprendibile.
Che abbia degli svantaggi è normale, alla fine è il paradigma di programmazione a più alto livello che esista, e ha solo la ricorsione e il costrutto condizionale. So che in Ocaml si sono risolti efficientemente problemi che non si sono riusciti a risolvere bene neanche in C, e che una società vende (e qualcuno glieli compra) pacchetti per il controllo remoto di aereomobili scritti in un linguaggio della famiglia ML.
let rec add_follows lst = match lst with
[] -> []
| head :: [] -> [head]
| head :: tail -> match add_follows tail with
[] -> []
| hd :: tl -> (add head hd) :: hd :: tl;;
Per me stanno troppo avanti, sti cammelli :D
E poi programmare con la ricorsione è molto più divertente che con l'iterazione :cool: :D
1) Ripeto, quello che per te è codice complesso in C++, per qualcun alto potrebbe essere chiaro come il sole. La modularità è poi inversamente proporzionale alla complessità, quindi cambiare una sola cosa, in C++, non è tanto peggi che cambiarla in un linguaggio "puffo".
2) Se davvero hai studiato Ingegneria del Software hai scritto un paradosso grosso come una casa, se pensi che per verificare la correttezza si debba procedere per infiniti dati di input, per induzione o per dimostrazione matematica: esistono alternative sia per l'analisi strutturale che funzionale.
3) Un linguaggio ricorsivo è pessimo sotto tutti i punti di vista funzionali. A meno che tu non abbia costruito un'architettura hardware ricorsiva, nel qual caso il discorso è duale. Il 99% delle macchine in commercio è di stampo iterativo.
Scoperchiatore
27-09-2005, 23:13
1) Ripeto, quello che per te è codice complesso in C++, per qualcun alto potrebbe essere chiaro come il sole. La modularità è poi inversamente proporzionale alla complessità, quindi cambiare una sola cosa, in C++, non è tanto peggi che cambiarla in un linguaggio "puffo".
E mi pare chiaro che le teorie moderne sul software design, sui design pattern, su XP e documentazione, vertono a standardizzare il concetto di complessità, proprio per abbattere i costi di manutenzione.
2) Se davvero hai studiato Ingegneria del Software hai scritto un paradosso grosso come una casa, se pensi che per verificare la correttezza si debba procedere per infiniti dati di input, per induzione o per dimostrazione matematica: esistono alternative sia per l'analisi strutturale che funzionale.
Forse non hai ben chiaro il concetto di correttezza:
da Wikipedia: http://it.wikipedia.org/wiki/Teorema_dei_quattro_colori
" La logica e la teoria dell'informazione ci dicono infatti che non è possibile dimostrare la correttezza di un algoritmo, ma è facilissimo dimostrarne la non correttezza, tramite una controprova. Ad ogni modo nell'algoritmo non è stato trovato alcun errore..."
Oppure da qua:
http://www.univirtual.it/corsi/2003/solitroFSEI1/download/modulo04.pdf
la definizione di Correttezza Totale:
Sia P <Pre, Post, Dom, Cod> un problema;
Sia A un algoritmo che calcola la funzione FI
Si dice che A è totalmente corretto rispetto alle specifiche del problema se per ogni x appartenente a Dom si verificano le 3 condizioni di correttezza semplice (che non scrivo per brevità)
Come ovvio, il "per ogni" implica che in un insieme denso come R sia impossibile dimostrare, se non matematicamente, questa affermazione con dei semplici test.
In questo senso ti ricordo che l'unico modo per asserire che un algoritmo A risolve un determinato problema è dimostrarlo matematicamente.
Un esempio è proprio il teorema dei 4 colori, da cui ho tratto la prima citazione. L'algoritmo non ha mai fallito, per ora. Ma non è ancora considerato corretto, in quanto sono ancora al vaglio le sue possibili dimostrazioni.
3) Un linguaggio ricorsivo è pessimo sotto tutti i punti di vista funzionali. A meno che tu non abbia costruito un'architettura hardware ricorsiva, nel qual caso il discorso è duale. Il 99% delle macchine in commercio è di stampo iterativo.
E ovviamente sai meglio di me che utilizzando la tail recursion, ottimizzi il codice ricorsivo rendendolo esattamente uguale a quello iterativo, dato che l'attivazione della procedura consiste soltanto nel posizionamento nello stack dei nuovi valori dei parametri con cui la procedura lavora, operazione equivalente (in tempo) alla modifica [i++] di un valore.
Il grande problema è che non tutto si può ottimizzare in tail recursion.
Il concetto che tento di esprimere è questo: non me ne frega niente di imparare C++, lo imparo da solo in 2 giorni, se voglio. Java e C mi bastano e mi avanzano.
E' stato fondamentale per me imparare Ocaml, comprendere questo paradigma di programmazione e la sua connessione con la teoria della calcolabilità e della complessità: è stato, più che altro, qualcosa di nuovo, cosa che non è C++.
Sono contrario ad un'università che mi dica le stesse cose più di due volte: una basta, due sono utili per ripassare. Ma oltre è predita di tempo.
ma io penserei prima a laurearmi, nessuno ha la sfera magica qui dentro...
ah cmq volevo dirti che di applicazioni pratiche di pc se è come meccnaica non ne vedrai mai, quindi regolati bene, parecchi a meccanica da me si credevano che si parlava di motori e roba varia, a me pacciono ma ero ocsciente che non li avrei mai approfonditi...
vedi prima quello che sai\vuoi fare tu...
poi vedi te...
p.s le ingengerie dipendono dalle persone, se a uno la matematica non piace elttronica sarà difficilissima, chi non piacciono determinate cose troverà difficile meccnaica e cosi via, ma dire che quelli sono superiori quelli inferiori mah...e inferiori\superiori a chi o cosa?
Forse non hai ben chiaro il concetto di correttezza:
da Wikipedia: http://it.wikipedia.org/wiki/Teorema_dei_quattro_colori
[...]
Se per te la correttezza di un programma equivale alla correttezza di un algoritmo allora siamo apposto. :)
La correttezza del programma non sempre si può verificare come dici tu, perché non sempre un programmatore si trova di fronte ad algoritmi matematici. Esiste un trilione di casi in cui non esiste una dimostrazione matematica, perché con la matematica poco ha a che spartire.
In questi casi vengono in ballo la logica e alcune leggi e linguaggi che permetto un'analisi statica alla ricerca di eventuali errori.
Secondo me, con la tua passione, ti stai fissando su una sfera molto ristretta della cosa. L'Ingegnere Informatico, secondo me, non è quello che dimostra formalmente una algoritmo, ma la validità del sistema.
Come avrai sicuramente studiato, ma anche con questa risposta credo che tu non abbia molto approfondito, l'analisi di un sistema passa per un numero strettamente finito di casi, i quali test seguono procedure piuttosto meccaniche regolate da particolari leggi. Un programma corretto, in sostanza NON è un programma per cui gli algoritmi non deducibili sono stati necessariamente dimostrati per induzione. Ti dirò di più, anche per gli algoritmi verificabili in un numero finito di casi, NON è richiesta la dimostrazione per tutti questi.
Ti ricordo anche che il dominio di un software è rappresentato dall'ambito in cui dovrà lavorare, pertanto NON è richiesta necessariamente la ricerca di errori in ambiti che vanno al di fuori delle specifiche dell'utente, salvo casi di clean-room o di contratto che richieda diversamente.
Riguardo la tail recursion che dire: un ottimo stratagemma per passare da algoritmo ricorsivo a quasi iterativo, con prestazioni -simili- e con lo svantaggio che il compilatore deve interpretare la modifica delle call e dei ritorni, nella speranza che lo faccia bene e senza mostrare necessariamente il codice al programmatore se non disassemblando l'eseguibile.
Insomma: ottima in ambito didattico o dove non sia possibile altrimenti in tempi ragionevoli. Sarà che a me piace di più pensare in iterativo, ma sovrabbondare di ricorsivo mi sembra uno spreco inutile.
Scoperchiatore
28-09-2005, 19:53
Se per te la correttezza di un programma equivale alla correttezza di un algoritmo allora siamo apposto. :)
Ti stai incastrando sul termine: correttezza è proprio questo, dimostrare che l'algoritmo è corretto.
Se poi si parla di "funzionamento corretto per i casi interessanti", allora ok.
La correttezza del programma non sempre si può verificare come dici tu, perché non sempre un programmatore si trova di fronte ad algoritmi matematici.
Un programma è sempre un algoritmo, al massimo complesso da codificare matematicamente, ma lo è sempre.
Ripeto, che poi non serva necessariamente codificare analiticamente un programma nell'algoritmo, è possibile, ma si spera che prima di scrivere codice, si abbia ben chiaro l'algoritmo.
Esiste un trilione di casi in cui non esiste una dimostrazione matematica, perché con la matematica poco ha a che spartire.
Esistono anche i trilioni di bug. Quello che tento di dirti da 2 pagine, è che se la matematica ti permette di dire "è giusto", allora sei SICURO che il tuo algoritmo non ha bug logici.
E questa possibilità con un linguaggio funzionale cell'hai spesso.
In questi casi vengono in ballo la logica e alcune leggi e linguaggi che permetto un'analisi statica alla ricerca di eventuali errori.
Secondo me, con la tua passione, ti stai fissando su una sfera molto ristretta della cosa. L'Ingegnere Informatico, secondo me, non è quello che dimostra formalmente una algoritmo, ma la validità del sistema.
Che non può prescindere dalla validità dei componenti. Come pretendi di DIMOSTRARE che il sistema è valido, senza dimostrare la validità di tuttli gli algoritmi che esso utilizza?
Al solito, il problema è il termine. Dimostrazione matematica rigorosa non serve in molti casi, bastano i test. Ma con un test non puoi affermare di aver dimostrato qualcosa. Hai solo capito che, molto probabilmente, hai fatto un buon lavoro (e credo che siamo d'accordo con l'affermare che è questo quel che server in molti casi)
Come avrai sicuramente studiato, ma anche con questa risposta credo che tu non abbia molto approfondito, l'analisi di un sistema passa per un numero strettamente finito di casi,
No, ho studiato l'opposto, che un sistema va analizzato in un numero infinito di casi per aver la certezza che funzioni.
i quali test seguono procedure piuttosto meccaniche regolate da particolari leggi.
Poi ho anche studiato che se considero i casi più importanti, quelli limite e quelli meno comuni, posso impostare un test che mi permette di dire che il mio sistema "funziona". Ma non me ne può dare la sicurezza.
Un programma corretto, in sostanza NON è un programma per cui gli algoritmi non deducibili sono stati necessariamente dimostrati per induzione.
E invece lo è.
Sempre solita storia, il termine non va inteso nell'accezione comune.
Ti dirò di più, anche per gli algoritmi verificabili in un numero finito di casi, NON è richiesta la dimostrazione per tutti questi.
Insomma, dato che 2 al quadrato fa 4, posso calcolare il quadrato di ogni numero moltiplicandolo per due, visto che in quel caso particolare, il doppio e il quadrato coincidono?
La tua affermazione implica questo.
Ti ricordo anche che il dominio di un software è rappresentato dall'ambito in cui dovrà lavorare, pertanto NON è richiesta necessariamente la ricerca di errori in ambiti che vanno al di fuori delle specifiche dell'utente, salvo casi di clean-room o di contratto che richieda diversamente.
Tu parli di software, io di algoritmi: forse hai in mente altri obiettivi.
Usando Java sono abituato alla riusabilità di tutto, e non progetto più quasi nulla per un uso "singolo".
Mi è capitato di risolvere un problema di covering, e ho progettato e fatto le classi per un uso generale, indipendente dall'uso relativo al problema più grande che mi aveva fatto scontrare col problema di covering.
Per me sarebbe stato molto importante poter scrivere su carta una dimostrazione del mio codice, in quanto avrebbe significato che quella "mini-libreria" covering è sempre utilizzabile da chiunque senza paura, perchè è DIMOSTRATO che funzionerà sempre e ovunque.
Ti pare poco?
Se poi pensi a un software che una volta fatto, viene modificato poco, e mai riutilizzato in altri ambiti, sono certo che non ti scontrerai mai con una dimostrazione formale di correttezza. E forse non succederà mai neanche a me.
Però chi fa il ricercatore, sarebbe molto avvantaggiato nel dimostrare la fondatezza e l'importanza del suo lavoro, se riuscisse a completare una dimostrazione formale di correttezza. Se poi non ce la fa, amen, si fa i suoi 30 test, verifica che funzionano, e dice che funziona. Ma nota che le due cose sono ben diverse, probabilmente fa la differenza fra un buon lavoro di ricerca e un eccellente lavoro di ricerca.
Riguardo la tail recursion che dire: un ottimo stratagemma per passare da algoritmo ricorsivo a quasi iterativo, con prestazioni -simili- e con lo svantaggio che il compilatore deve interpretare la modifica delle call e dei ritorni, nella speranza che lo faccia bene e senza mostrare necessariamente il codice al programmatore se non disassemblando l'eseguibile.
Insomma: ottima in ambito didattico o dove non sia possibile altrimenti in tempi ragionevoli. Sarà che a me piace di più pensare in iterativo, ma sovrabbondare di ricorsivo mi sembra uno spreco inutile.
Su questo hai ragione, ma i vantaggi di cui sopra, in alcuni ambiti, non sono mica da ridere.
Il limite del tuo ragionamento è che sulla carta si ha a che fare con simboli logico-matematici che seguono una sintassi e una semantica precise.
La modellizzazione di un listato, però, non è sempre perfetta, anche perché banalmente le istruzioni (che vengono create soprattutto in funzione di una semplice e ottimizzata gestione dei bit dei registri prima che nell'utilità delle funzioni stesse) vengono eseguite su una macchina che ha diversi difetti correlati. Un computer non è un sistema perfetto, altrimenti se prendi un intero su 32bit (ormai dovremo fare anche per 64 ^_^), completamente settato, e me lo incrementi, cosa succede?
Sulla carta nulla di strano, si aggiunge una cifra binaria. Nella macchina una mazza! Si resetta l'intero e si setta il bit di overflow.
Ecco perché quando si analizza qualcosa non si cerca sempre di matematizzare tutto, non perchè gli Ingegneri siano "brutali", ma piuttosto perché non tutto è così esatto come farebbe comodo che fosse.
Per piacere non dirmi che è un caso un po' limite, lo so bene, ma è il primo esempio che mi è venuto in mente.
Il discorso credo si risolva a priori: qui stiamo parlando di Ingegneria Informatica, quindi se proprio vogliamo fasciarci la testa con polemiche sterili sarà sulla correttezza del prodotto software in primis, solo successivamente dell'algoritmo.
Altrimenti mi parli di programmazione in generale, arte che viene esercitata da un numero ben maggiore di persone di persone rispetto agli Ingegneri Informatici.
Se Fox avesse chiesto di Informatica in generale, allora si portebbe anche discutere su ciò che uno preferisce fare ed individuare un CdL adatto. Se già si nota un minimo orientamento verso la sfera ingegneristica bisogna vertere verso la concezione ingegneristica di processo di sviluppo più che di correttezza di singoli moduli, che per l'appunto spessissimo vengono realizzati da programmatori professionisti non-ingegneri; gli Ing, dal canto loro, si occupano dell'integrazione, test d'integrazione, convalida e verifica. Prima della codifica si occupano principalmente di raccolta e analisi dei requisiti, nonché del progetto.
Non è che il tuo sogno è sempre stato quello di diventare un Dottore in Informatica ed hai semplicemente imboccato una strada diversa?
I tuoi discorsi un po' lo fanno trapelare, e non c'è nulla di strano: l'ho visto un sacco di volte sia in un verso che nell'altro. :)
PS: sul 2*2=4 => n*2=n^2 non espongo commenti perché è una forzatura sciocca di un ragionamento applicato in qualsiasi programma che usi quotidianamente, dal compilatore, al browser, al sistema operativo :)
Scoperchiatore
28-09-2005, 22:54
Il limite del tuo ragionamento è che sulla carta si ha a che fare con simboli logico-matematici che seguono una sintassi e una semantica precise.
La modellizzazione di un listato, però, non è sempre perfetta, anche perché banalmente le istruzioni (che vengono create soprattutto in funzione di una semplice e ottimizzata gestione dei bit dei registri prima che nell'utilità delle funzioni stesse) vengono eseguite su una macchina che ha diversi difetti correlati. Un computer non è un sistema perfetto, altrimenti se prendi un intero su 32bit (ormai dovremo fare anche per 64 ^_^), completamente settato, e me lo incrementi, cosa succede?
Sulla carta nulla di strano, si aggiunge una cifra binaria. Nella macchina una mazza! Si resetta l'intero e si setta il bit di overflow.
Ecco perché quando si analizza qualcosa non si cerca sempre di matematizzare tutto, non perchè gli Ingegneri siano "brutali", ma piuttosto perché non tutto è così esatto come farebbe comodo che fosse.
Per piacere non dirmi che è un caso un po' limite, lo so bene, ma è il primo esempio che mi è venuto in mente.
Non credo che riguardi quello di cui stavamo parlando.
Il discorso credo si risolva a priori: qui stiamo parlando di Ingegneria Informatica, quindi se proprio vogliamo fasciarci la testa con polemiche sterili sarà sulla correttezza del prodotto software in primis, solo successivamente dell'algoritmo.
Perdonami, ma secondo me io e te abbiamo 2 concezioni diverse di praticamente tutto ciò che riguarda l'informatica. Il pacchetto software non si crea da solo, lo fai tu, io, un altro, con la consapevolezza di fare qualcosa di "giusto". Mi puoi dimostrare matematicamente che lo è? Ottimo, il datore di lavoro sarà contento perchè non ti dovrà pagare ancora o non dovrà pagare un altro per rimediare ai tuoi errori. Non me lo dimostri? E' classico, si troverà il bug, e si sistemerà.
Non ti ho parlato di tutta la realtà, ti parlo di possibilità teorica e di ambiti precisi. Un ricercatore non lavora come un ingegnere privato o assunto da qualche azienda. Ed è pieno di ricercatori che hanno "Ing" davanti al titolo.
Se Fox avesse chiesto di Informatica in generale, allora si portebbe anche discutere su ciò che uno preferisce fare ed individuare un CdL adatto. Se già si nota un minimo orientamento verso la sfera ingegneristica bisogna vertere verso la concezione ingegneristica di processo di sviluppo più che di correttezza di singoli moduli, che per l'appunto spessissimo vengono realizzati da programmatori professionisti non-ingegneri; gli Ing, dal canto loro, si occupano dell'integrazione, test d'integrazione, convalida e verifica. Prima della codifica si occupano principalmente di raccolta e analisi dei requisiti, nonché del progetto.
ma, se ti ricordi bene, il discorso era partito dal fatto che la matematica pura era meno importante del saper programmare. E io, da questo tuo discorso, deduco che l'ingegnere come lo vedi tu debba sapere quasi soltanto matematica (che sia logica, calcolo statistico o algebra), e possa dimenticarsi la programmazione, tanto la fanno gli altri (cosa MAI vera, tra l'altro).
Non è che il tuo sogno è sempre stato quello di diventare un Dottore in Informatica ed hai semplicemente imboccato una strada diversa?
Ni. Mi piace la teoria dell'informatica, ma solo da poco.
PS: sul 2*2=4 => n*2=n^2 non espongo commenti perché è una forzatura sciocca di un ragionamento applicato in qualsiasi programma che usi quotidianamente, dal compilatore, al browser, al sistema operativo :)
E sul fatto che per dimostrare qualcosa basta analizzare solo casi particolari, io non spendo altre parole, perchè se così fosse, avresti guadagnato il milione di dollari messo in palio per dimostrare la congettura di goldbach ;)
Sulla teoria della correttezza hai le idee poco chiare, IMHO, ma d'altronde, come hai sottolineato, spesso è impossibile applicarla, quindi forse avrai pensato che è inutile sprecarci troppo tempo.
Un contributo al thread che posso dare (dato che l'ho fatto andare OT per troppo tempo) è che il lavoro dell'ingegnere informatico è probabilmente uno dei più impredittibili nel moderno mercato.
Uno che conosco è direttore di aereoporti;
un altro fa sistemi bancari complessi in giro per il mondo;
altri fanno i programmatori;
altri ancora timbrano e siglano carte, senza mai vedere un PC se non per usare Office;
un team di ingegneri informatici (provenienti dall'IBM, credo) è stato recentemente "assoldato" da una società bancaria per risolvere l'annoso problema delle informazioni disperse nelle banche telematiche alla chiusura dei mercati (e alla fine dell'anno di lavoro, hanno prodotto, guarda te, algoritmi; niente codice, quello era la parte meno significativa)
altri fanno consulenze private in giro, guadagnando cifre elevate (ovviamente solo se bravi)
molti lavorano per la pubblica amministrazione (si sa, paga tanto) e non fanno altro che programmare un po' più ad alto livello rispetto ai colleghi programmatori.
e chi più ne ha più ne metta.
Chissà cosa faremo noi....
Perdonami, ma secondo me io e te abbiamo 2 concezioni diverse di praticamente tutto ciò che riguarda l'informatica. Il pacchetto software non si crea da solo, lo fai tu, io, un altro, con la consapevolezza di fare qualcosa di "giusto". Mi puoi dimostrare matematicamente che lo è? Ottimo, il datore di lavoro sarà contento perchè non ti dovrà pagare ancora o non dovrà pagare un altro per rimediare ai tuoi errori. Non me lo dimostri? E' classico, si troverà il bug, e si sistemerà.
Guarda, fammi conoscere il tuo datore di lavoro perché sarei felice di lavorare per qualcuno che si accontenta della correttezza formale di un algoritmo... mai sentito parlare di revisione additiva o di revisione di piattaforma? Un algoritmo corretto è solo un primo passo. Evidentemente per te la revisione correttiva, o meglio, come evitarla, è più importante che per altri, ma ti assicuro che non tutti la pensano strettamente così.
ma, se ti ricordi bene, il discorso era partito dal fatto che la matematica pura era meno importante del saper programmare.
Per un matematico no, per un informatico sì. Tu dici che in poche ore sai approcciarti ad un linguaggio di programmazione a oggetti stile C++. Io non lo credo possibile a meno che tu non abbia particolari doti di genio. Saper programmare bene in un linguaggio ad alto livello non garantisce risultati a priori con altri linguaggi, soprattutto se passi da un linguaggio a maggiore complessità (e non di poco) come Java>>C++.
E io, da questo tuo discorso, deduco che l'ingegnere come lo vedi tu debba sapere quasi soltanto matematica (che sia logica, calcolo statistico o algebra), e possa dimenticarsi la programmazione, tanto la fanno gli altri (cosa MAI vera, tra l'altro).
No, deduci male visto che l'ingegnere informatico deve essere non proprio l'opposto di quello che hai scritto, ma un bilanciamento delle cose. L'Ingegnere Informatico programma, ma non è il suo compito principale. Uno specialista di reti, ad esempio, salvo pochi script .sh per automatizzare compiti rognosi nella gestione di account, backup e reminders, alla fin fine programma ben poco.
E sul fatto che per dimostrare qualcosa basta analizzare solo casi particolari, io non spendo altre parole, perchè se così fosse, avresti guadagnato il milione di dollari messo in palio per dimostrare la congettura di goldbach ;)
Prima ti scrivo che nn necessariamente va dimostrato qualcosa in maniera formale, poi dici che sostengo una teoria personale riguardo alla dimostrazione di qualcosa... fai te: conosco già tante parole senza che qualcuno me ne regali :)
Sulla teoria della correttezza hai le idee poco chiare, IMHO, ma d'altronde, come hai sottolineato, spesso è impossibile applicarla, quindi forse avrai pensato che è inutile sprecarci troppo tempo.
Non finisco di dire che non necessariamente si deve dimostrare la correttezza e mi aggiungi che non conosco come si dimostra... vedi sopra :confused:
[/QUOTE]Un contributo al thread che posso dare (dato che l'ho fatto andare OT per troppo tempo) è che il lavoro dell'ingegnere informatico è probabilmente uno dei più impredittibili nel moderno mercato.
Uno che conosco è direttore di aereoporti;
un altro fa sistemi bancari complessi in giro per il mondo;
altri fanno i programmatori;
altri ancora timbrano e siglano carte, senza mai vedere un PC se non per usare Office;[/QUOTE]
Vero: sostanzialmente un Ing Informatico trova lavoro in qualunque azienda che ospiti o necessiti di ospitare, una piattaforma informatica. Tutto questo escludendo l'ormai sempre più comune tele-lavoro.
Chissà cosa faremo noi....
Spero qualcosa che possa essere d'aiuto per un mondo migliore :)
Scoperchiatore
29-09-2005, 16:43
Io direi che è giusto chiuderla qua ;)
Abbiamo due idee differenti, e decisamente contrastanti, della stessa professione e di cosa ci può essere utile. Con l'esperienza magari capiremo fin dove avevamo ragione.
:cincin:
Questo la dice lunga su come variegata possa essere la vita di un Ingegnere Informatico :) Accorrete numerosi! :D
sentito dire: è molto impegnativa...poi fai tu... :D
sentito dire: è molto impegnativa...poi fai tu... :D
Verissimo, dopotutto è un investimento: dopo esserti fatto un mazzo tanto hai la possibilità di aspirare a incarichi interessanti.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.